Особенности национального Agile

Мой путь к осознанному использованию скрама лежал через много лет чистой практики (свой первый интернет-проект в команде с 1 разработчиком и 1 автором я начинал делать еще в 2005 году). Первый трекер задач (Mantis) использовал только в 2007-м. А целенаправленно дробить большие задачи на подзадачи осознанно стал не раньше 2010 года. Это крайне долгий путь, направление которого менялось в зависимости от рельефа проектов: размеров команд, компетенции специалистов, амбиций инвесторов и пр.

Долгое время я довольствовался теми выводами, которые нарабатывал сам, черпал при коммуникации с другими специалистами и в статьях. В определенный момент, чтобы общение с заказчиками проходило на одном языке, я засел за книжки. Было крайне любопытно читать о совсем другом пути Сазерленда, который привел меня к аналогичным выводам:

Про идеи и людей

Пропустим шаги составления плана, презентации и анализа похожих проектов. Как бы глубоко вы ни ныряли, все подводные камни можно узнать, только пройдя всю вертикаль процессов в проекте-конкуренте или набив свои шишки.

Минимальную версию любого сервиса, так называемый скелет проекта (речь не о шаблонном сайте на WordPress за $150), можно разработать за 3-4 месяца силами классической шестерки:

*Рейты применимы для middle/senior-специалистов в проектах западных компаний. В продуктах, ориентированных на внутренний рынок, планка ЗП редко перешагивает $3 000.

В зависимости от проекта у последних двух специальностей это может быть и part-time, уровень вовлеченности которого зависит от стадии разработки. Например, архитект будет нужен вам на фултайм в первые 2-4 недели, а потом только в качестве куратора. В то время как маркетолог, наоборот, будет актуален ближе к стадии бета-тестирования.

Так или иначе, с помощью такой конфигурации возможно реализовать черный ящик (проект без конкретных шаблонов и решений) любой сложности за 3-4 месяца, будь то мессенджер, соцсеть, биржа или любая другая человеческая блажь, связанная с IT.

Чем ближе прошлый опыт нанимаемого специалиста к области разработки, тем лучше. Он позволит двигаться более коротким путем и совершать меньше ошибок.

Избегайте part-time-специалистов. Искушение платить человеку «за результат» (мантра любого заказчика) очень велико. Но пока вы находитесь в стадии активной разработки, вам потребуется не только полное погружение в вашу идею, но и достаточно плотная коммуникация. Не думайте, что программисты будут участвовать в регулярных совещаниях и обсуждениях из любви к искусству. Даже если они не закладывают конф-коллы (или скайп-коллы) и встречи в прайс, поверьте, они их обязательно компенсируют рабочими часами по вашим задачам.

Исключение – только если вы предельно четко знаете, что вам надо, и можете прозрачно сформулировать все ТЗ.

Для любой идеи и бизнеса результативнее сформировать автономную команду крепких специалистов, силами которых реализовать скелет проекта, а дальше, уже по мере необходимости, подключать фрилансеров или расширять штат.

Я уже давал ранее совет не нанимать людей со скучными лицами. Повторю его еще раз. Не нанимайте даже очень компетентных людей, если им не интересен ваш проект, и не горят от работы глаза. С ними будет тяжело.

Право требовать

Требовательность к людям не может быть односторонней. Нельзя тянуть с ответами на вопросы, с предоставлением нужной информации, с решениями, но при этом требовать неукоснительного соблюдения сроков или правил. Нельзя ради дедлайнов забивать на какие-то аспекты (рефакторинг, тесты, качество архитектуры), но на совещаниях рассуждать о перфекционизме и высочайшем качестве продукта для аудитории. Прописывать в требованиях детализацию задач и хранить пустые таски с одними заголовками в трекере.

Ваши рабочие процессы станут внутренним отражением вашего будущего продукта. И если вы сами будете проявлять неуважение к правилам, аудитории – точно так же будут работать и другие.

Требовать качества, соблюдения сроков, вовлеченности можно только тогда, когда вы сами въе$%ваете, как ломовая лошадь. Вникаете и понимаете проблемы проекта, помогаете их устранять. Только тогда люди чувствуют уместность этих требований и подчиняются им.

Это же касается и оплаты. Вы не можете ждать от людей соблюдения сроков, если не обеспечиваете регулярность, полноту выплат денег вовремя.

Культура разработки появляется не снаружи, на основе чужого опыта из книжек и статей, а формируется изнутри, на стыке требований продукта и возможностей команды.

Молчание – вред

Вторая, после слабой компетенции, главная проблема внутри команд – отсутствие коммуникации, понятных и простых процессов и прозрачных критериев оценки результатов работы.

Принцип один – регулярно общаться. Собирайте всех ключевых сотрудников по каждому направлению, из числа вовлеченных в разработку, и вместе планируйте и подводите итоги спринтов:

Можно сказать дизайнеру, что на его баннер хорошо кликали и благодаря этому маркетологу удалось достичь хороших показателей. Или сообщить, что новый формат оформления статей улучшил время просмотров и глубину на 20 % – читатели в восторге, как и редакция. Понимание целей задач и результатов своей работы очень мотивирует специалистов.

В-третьих, на примере чужих ошибок или полезных находок люди могут корректировать свои процессы.

Любое планирование и подведение итогов призвано улучшить текущие процессы, сделать более прозрачными, быстрыми и прогнозируемыми, отсечь лишнее.

Четкие и понятные всем задачи, процедуры позволяют людям работать в комфортном режиме, когда они могут сопоставить свои возможности с задачами. Для программистов это означает небольшие, емкие задачи, которые могут объединяться в эпики, пользовательские истории или просто большие задачи. Людям очень тяжело заходят портянки с детально расписанным функционалом. Еще сложнее эти портянки воплощаются в жизнь.

Чем объемнее задача – тем сильнее прыгнут сроки, тем больше она будет отличаться от концепции и тем больше в ней будет багов. Разбивайте большие задачи на подзадачи. По опыту, все, что в черновом виде делается дольше 4-8 часов, должно дробиться на подзадачи.

То же самое касается критериев оценки. Нарисуй красиво, реализуй без багов, запости сущность из документа – это все не дает человеку понимания, а вам нужного результата. Оговаривайте, а лучше прописывайте критерии, по которым будут приниматься задачи (как разовые, так и рутинные). Например, если речь идет о верстке, то не пишите «должно поддерживаться во всех браузерах на всех платформах». Это бред. Достаньте статистику по вашей потенциальной аудитории – популярные браузеры, устройства, разрешения экранов – и подгоняйте верстку под них. А не ставьте верстальщику перфекционистские цели по адаптивности под все.

Задача ПМ/скрам-мастера – минимизировать усилия там, где это будет на пользу проекту.

Сова на глобусе

Не пытайтесь выстраивать взаимодействие по скраму со средними специалистами. Бессмысленно ждать полезной и осознанной вовлеченности в проект от людей со слабыми скиллами. Если в силу обстоятельств, горящих сроков и недофинансирования вы сформировали не самую компетентную команду, проявите волю. Берите ответственность за решения на себя, а людей используйте просто, как живые инструменты. В такой ситуации работает только здоровый деспотизм и единоначалие, когда вы транслируете четкие задачи, и остальные просто реализуют их.

Это не самый легкий путь, требующий от вас хороших знаний в самых разных областях, а от ваших коллег – доверия и честности по отношению к вам.

В большинстве случаев такой принцип взаимодействия будет сводиться к стоянию с палкой над людьми, что выматывает до предела. Пройти через такое полезно, хотя бы для того, чтобы понимать разницу между сработанной командой и просто исполнителями.

Время без фичей

Всегда закладывайте время на рефакторинг кода, написание тестов и черновое тестирование нового функционала разработчиками. Чем больше у вас функционала – тем плотнее он должен быть обвешан синтетическими тестами.

Язык специалистов

Договаривайтесь о терминологии и синонимах. Старайтесь использовать 1 термин для определения 1 сущности или процесса. Так вы будете легче понимать друг друга, и не возникнут ситуации с ошибочными интерпретациями задач.

По лезвию бритвы

Нельзя топить за одну из сторон – разработчиков или заказчика. Ваша задача – ходить по лезвию бритвы, получать от разработчиков максимальную отдачу, а от заказчика – оптимальный уровень обратной связи и инвестиций.

В момент, когда баланс рушится, ваш проект терпит крушение, сродни поезду, который пытается ехать только по одной рельсе.

Все разработчики делают это

Старайтесь быть в курсе планов и важных жизненных моментов ваших коллег. Люди не роботы. Они ездят отдыхать, болеют, впадают в депрессии, у них могут болеть близкие и случаться различные коллапсы. Это жизнь. Чем меньше вы будете негативно резонировать в таких ситуациях и больше проявлять человечности, тем лучше. Если кто-то начнет пользоваться этим, вы сможете попрощаться с ним в любой момент.

Пример из жизни. Особенно это относится к аутсорс- и аутстаф-командам. В моей жизни был очень неприятный инцидент, когда ПМ команды аутсорсеров забыл сообщить, что ключевой разработчик уходит в отпуск на 2 недели из-за свадьбы. Выяснилось это за три дня до торжества, в разгар переезда огромного портала с php на python (для непосвященных – переезд со всеми вещами, родственниками, друзьями и их вещами из Хацапетовки в Нью-Йорк своим ходом), дичайшего багфикса и тотального срыва сроков. Менеджер был полный мудак, разработчика, естественно, пришлось отпустить, релиз перенести, а я на всю жизнь выработал привычку опрашивать коллег про даты планируемого отдыха.

Время – деньги

Всегда четко проговаривайте условия взаимодействия. Для part-time-специалистов – нагрузку на ближайшие недели и ее распределение по дням, для постоянных – сроки выплат, бонусы и прекращение сотрудничества. Оптимальным считается двухнедельный срок для уведомления об увольнении, чтобы человек мог подыскать новую работу, доделать оставшиеся задачи и сдать свои обязанности другому специалисту.

Перекрестное опыление

Старайтесь детально разбирать ошибки, которые приводили к срыву сроков, и экстраполировать ускорения на другие процессы и задачи. Перекрестное опыление отлично работает, когда ПМ задействован сразу на нескольких проектах и может применять опыт разных команд.

Плагины, фреймворки, сервисы

Используйте готовые решения там, где это возможно. Например, тут https://codecanyon.net можно найти практически любой фреймворк или плагин, который станет основой для вашей идеи и MVP:

Помните об ограничениях таких решений и несовершенстве. Воспринимайте как времянку-палатку для похода в лес на пару дней, но не как постоянное жилье. Очень часто заказчики питают иллюзии, что можно использовать такие вещи для чего угодно – от создания соцсети до маркетплейса. Это форменное безумие, и идти на поводу у такого не стоит.

Честность стоит денег

Меньших, чем те, на которые вас будут пытаться кинуть, но вполне ощутимых.

Пример из жизни. Недавно я был свидетелем того, как в соседней команде двух разработчиков поймали на типовой схеме перепродажи своих же рабочих часов. Активно изображая бурную деятельность и в какой-то момент получив слишком большой кредит доверия от генерального, разрабы стали жаловаться на большие объемы задач и просить помощи. В нужный момент, отпихнув десяток кандидатов от HR, порекомендовали «проверенных» людей, которыми, естественно, были они сами. История вскрылась с приходом нового техдира, когда два веселых гуся успели освоить почти $50к. Вопрос был поставлен ребром: или их увольняют, или техдир не вступает в должность.

В другой похожей истории 7-летней давности я уже был участником. Команда аутсорсерсов вальяжно переносила проект на другой язык, регулярно срывала сроки и вызывала на тот момент острое желания взять палку и больно бить всех по головам до получения нужного результата.

Три месяца я убеждал коллег, что подрядчик нас кидает, и над проектом работает 1 человек, вместо 4 числившихся в сметах и получавших ЗП. 90 дней ежедневного жевания одной и той же темы, из них месяц полного погружения в работу проблемного отдела, чтобы доказать свою правоту. Иногда я бываю запредельно упертым и невыносимо занудным. В такие периоды я напоминаю смесь бульдога и пары волов, которые тянут тяжеленную повозку под палящим солнцем. Решилось все простым разговором по душам (у фразы нет второго дна), после которого разработчик во всем признался.

Цена возможных потерь была меньше, но тогда мне казалась какой-то безумной – $30к. Компания сохранила эти деньги, получила ценный кадр (несмотря на эмбарго на хантинг людей у подрядчика), вокруг которого позже выстроили с нуля технический отдел, а я перестал пытаться обогнать время.

Не бойтесь увольнять

Ключевых причин не так много:

• Однотипные ошибки, необучаемость человека.

• Конфликты с командой.

• Перманентный срыв сроков, высокий процент багов в релизах.

• Обман в рабочих или финансовых вопросах.

В каждом из этих случаев полезнее и для человека, и для проекта, и для команды – расстаться. Порой это очень страшно, поэтому нужно просто брать и делать. Увольнять, нанимать новых людей, интегрировать их в проект. И разгребать говнокод за прошлыми разработчиками.

Пример из жизни. У меня был очень печальный опыт полной замены технического отдела на живом, стремительно растущем проекте. Ситуация была патовой – баги и краши проекта росли в геометрической прогрессии, аудитория – еще быстрее. В какой-то момент пиковой турбулентности технический отдел передали мне. Я потерял в тысячу раз больше сил и нервов, по полной хапнув негатива, пока пытался наладить работу с проблемными кадрами, работавшими там со старта. Я перепробовал все – от штрафов и премий до детально прописанных тасков и ежедневных совещаний, прежде чем понял: эти люди физически не способны работать лучше. Просто не могут писать код без феноменального количества багов, а какие-то задачи не способны решить в принципе. И требовать от них иного – как пытаться заставить слона залезть на дерево.

Путь был один – увольнять старых прогов, брать сильного специалиста извне и выстраивать вокруг него новую команду. Или хоронить проект. Руководство рискнуло, и спустя 2 месяца темп разработки вырос в сотни раз, превратившись из адского пиз%&ца в песню, со спринтами, командой QA-волонтеров, автоматическими тестами и стабильными релизами, после которых проект работал, а не падал каждые пять минут.

Такое происходит не всегда. Иногда, работая со старыми технологиями и платформами, и я, и проект становились заложниками некомпетентного технаря. Тогда единственным способом остановить обоюдные мучения было заморозить проект.

Дерьмо мамонта

Не связывайтесь со старыми технологиями и платформами. В большинстве случаев специалисты, готовые с ними работать, или ленивы, или глупы, или одновременно все.

Быть в потоке

Не откладывайте багфикс надолго. Причем это касается всего – и дизайна, и разработки. Людям легче работать, находясь в контексте задачи. И переключившись на другую, они потратят больше времени, вновь погружаясь в контекст, чем на сами правки. Не прыгайте по задачам, а сосредоточьтесь на завершении каждой на 100 %. Чем больше у вас незавершенных задач, тем больше времени вы будете тратить, переключаясь между ними.

Человек в целом существо абсолютно однозадачное. Я долгое время находился в иллюзии обратного, считая себя очень многозадачным. Тем же мифом живут и другие. Для разрушения этого вам потребуется листок бумаги и ручка. Напишите слева направо буквы латинского алфавита, арабские и римские цифры:

А 1 I

B 2 II

…

И так до 10. Слева направо. А затем повторите эту же операцию, но сверху вниз, проставляя сперва буквы, потом один тип цифр и другой. Примерно так же ваш мозг работает над параллельными задачами, только разница усугубляется в тысячи раз.

Прощайтесь с идеями без сожаления

Не бойтесь хоронить в бэклоге детально расписанные задачи и макеты. Это лучше для проекта, чем в угоду чьих-то амбиций реализовывать ненужный функционал.

Инвесторы – тоже люди

Не форсируйте вопрос увольнения некомпетентных сотрудников, которых вам навязывает руководство. Инвесторы – заложники конечной цели. Чтобы проект развивался, нужны люди. Если вы не даете шанса раскрыться новым сотрудникам, сразу начинаете требовать убрать балласт – вы ставите под сомнение выбор заказчика и обесцениваете его желание развивать проект. Не торопитесь, обычно достаточно 1-4 недель, чтобы специалист показал все свои достоинства и недостатки.

Пример из жизни. Впрочем бывают и исключения. Однажды я наблюдал, как руководитель отдела маркетинга полгода ведет проект, не понимая даже на 1 % его суть, выезжая только на том, что повторяла на совещаниях сказанные инвестором 5 минут назад тезисы. Если бы не видел такое лично, я бы не поверил. Техдир, когда тоже просек эту мутку, как-то потратил 2 часа на конф-колл с ней, после которого, схватившись за голову, матерясь ушел курить в полной прострации от глубины непонимания и полной некомпетенции.

Паразиты

Помогайте друг другу, но не позволяйте паразитировать на себе. Нередко в компании есть балластовые люди, которые выживают только за счет харизмы и умения паразитировать. Маркетолог из примера выше держала на зарплате целый виртуальный отдел и умудрялась напрягать других сотрудников делать все: начиная от настройки контекстной рекламы, доработки лендингов, написания слоганов и заканчивая конфигурацией Мейлчимпа. Не спрашивайте, как ей это удавалось. Порой в жизни происходят вещи за гранью моего понимания.

Спринты

Короткие однонедельные спринты актуальны только на начальном этапе, в период активной разработки. В дальнейшем переключайтесь на двухнедельные циклы релизов – людям легче работать на средней дистанции, чем частить с планами, ретроспективами и сборкой релизных версий, которые всегда априори стресс.

Это не противоречие

Прогнозы и сроки

В разработке возможно спрогнозировать результат только в тех задачах, которые являются калькой уже ранее сделанных теми же специалистами. Не пытайтесь выжимать из коллег более удобные даты: «А давай попробуем быстрее – это очень важно!». В любом случае чаще всего первичная оценка окажется реальной, а выцыганенные сроки все равно будут сорваны.

Кастомная разработка, как бы детально она ни расписывалась, всегда черный ящик. Но чем больше вы работаете над проектом, тем более точно специалисты могут оценивать задачи. Обычно спустя 3-6 месяцев сроки ползут не более, чем на 20 %.

Не практикуйте умножение на два названные вам сроки. Это расслабляет команду, обесценивает важность дедлайнов и действует порочно.

Жизнь в норе

Избегайте людей, не готовых к нововведениям и изменениям. Каждый проект и команда – это определенный воркфлоу: правила, процедуры, среда разработки. Специалисты, которые без четкой аргументации начинают бойкотировать общие правила и упорно сидят в норе – головняк и недвусмысленный сигнал о слабой или узкой компетенции человека. Проявляться это может по-разному:

Иногда упертость граничит с тупостью, иногда на то есть причины. Чаще это просто нежелание человека вникать в новое. Другого способа, кроме как спрашивать и вести диалог, для решения этой проблемы нет.

Костные, не готовые меняться и принимать новые знания люди очень тяжелые в коммуникации и проблемные при командной работе. Берите таких только при острой необходимости или их высокой компетенции. Но помните, что они будут требовать от вас гораздо больше времени, чем другие.

Тайны мадридского двора

Интриги могут быть полезными, если они направлены на улучшение проекта, оптимизацию расходов и достижение общей цели. Но их категорически нужно пресекать, если они нацелены против других людей. Команда – не серпентарий.

Пример из жизни. Как-то в период бурного расцвета соцсетей в отдел разработки прилетел развесистый таск от SMM-специалиста, сильно выходивший за грани возможностей разработчиков. Адскими усилиями, остановив все остальные задачи, ребята сделали то, что надо, в срок. Спустя пару недель прилетела абсолютно другая, еще более забористая задачка. От безуспешных попыток объяснить SMM-специалисту, что такое сжигание ресурсов для единоразовых ивентов напоминает костер из денег, у меня сводило скулы, хотелось просто дать в морду. Объяснять идиотизм ситуации руководству нерационально. Это был период быстрого роста, и неделя разработки в плюс, неделя в минус – на короткой дистанции особо никого не волновала. Я связался с директором по рекламе и сказал:

– Женя, мы можем сделать функционал под ивенты, который ты сможешь продавать минимум год, с прозрачной и понятной для заказчиков механикой, кейсами, которые будут драйвить постоянно новых клиентов, как магнит. По стоимости для нас в 20 раз дешевле, чем то, что делали последнее время, и тратимся на разработку только 1 раз. Продавать легко за любой прайс. Хочешь?

– Хочу!

– Продави эту идею руководству, чтобы никто не трогал моих людей, и мы могли спокойно развивать ресурс, не отвлекаясь на рекламу. И мне не е&#ли мозг дебильными тасками по конкурсам разным.

Мы работали вместе не первый месяц и понимали ценность друг друга без долгих разговоров. На следующем совещании топов Женя встала и задала простой вопрос: «Почему мне не дают зарабатывать деньги для компании? Мы слишком богатые?»

Слишком богатым себя никто не считал. Сверху прилетело добро на игнор всех задач. За неделю мы собрали функционал под проведение викторин и раздачу ключей в онлайн-игры, удачно запустили пилот по STALKER, Diablo 3 и TES, собрали около 100 000 участников суммарно за первые три ивента (примерно в 200 раз больше, чем странные акции от SMM-специалиста), и Женя еще пару лет успешно продавала эти механики всему рынку, начиная от 1C, Blizzard, Innova и заканчивая Sony, LG и другими китами.

Сделанная один раз презентация расширялась только скриншотами особо крупных клиентов или совсем безумно высоких результатов и продавала сама себя, челночным способом. А разработчики спокойно сели за плановые задачи без опасений, что их снова попросят срастить единорога с совой для реализаций творческих фантазий очередного юного дарования.

Таск-трекеры

Воспринимайте любой таск-трекер как инструмент, а не решение всех проблем. В зависимости от специфики проекта, размеров и количества команд и выбирайте наиболее подходящий.

Trello – легкий, удобный, быстрый облачный трекер. Идеально подойдет для простых проектов или редакций.

Redmine – функциональный, но застрявший далеко в прошлом трекер, с возможностью локального развертывания на собственном сервере. Подойдет для больших проектов с большим количеством не связанных между собой команд.

Jira – мастодонт из мира энтерпрайза, рассчитанный исключительно на крупные проекты. Чудовищно неудобная и тяжелая, но используемая повсеместно.

Asana – более продвинутый вариант Trello, с массой внешних решений для интеграции, у которого за годы существования так и не появилось поле «время».

Worksection – украинский аналог Asana. Не такой быстрый и удобный, зато более развесистый функционал и дешевле.

Список можно продолжать до бесконечности. Есть модный среди хипстеров Basecamp, по-прежнему живой Mantis, хардкорный Utrack и масса других. У всех есть бесплатные или триал-версии, поэтому при желании подобрать наиболее предпочтительный для текущего проекта вариант не составит труда.

Обращайте внимание на:

Запрет на переработки

Увлеченные работой люди, особенно не обремененные семьей, часто злоупотребляют работой ночами и по выходным. Допиливая в коммуникационной тишине наиболее сложные задачи или подтягивая хвосты. Это очень порочная практика. Обычно уже на следующая неделе после рабочих выходных продуктивность падает на 30-50 %. А через месяц кранчей наступает депрессия и выгорание с потерей интереса к проекту. Большинство не отлавливает эти моменты, находясь в иллюзии собственной выносливости и многозадачности.

Если вы строите долгосрочный проект – запрещайте работу по выходным.

Внутренний параноик STOP

Предварительная оптимизация – самое большое зло. Об этом писал еще в 1974 году Кнут, и с тех пор ничего не поменялось. Программисты по-прежнему тратят львиную долю времени на копание вглубь, там, где это никому не надо. Решая проблемы, которые никогда не произойдут. Страдают этим все без исключения – редакторы, дизайнеры, верстальщики. Поэтому чаще фокусируйте людей на поставленных задачах и не давайте им погружаться глубже, чем требуется.

Канбан

Я убежденный сторонник канбана из-за его понятности, простоты и наглядности. Выстраивать в нем процессы можно для любой группы специалистов.

Вот так может выглядеть доска для новостников:

В бэклог все новостники кидают подходящие новости. Берут в работу без риска писать одновременно одну новость двум людям, перетаскивают в опубликованное. И видят контекст вчерашнего дня. При необходимости в процесс встраивается редактор в роли модератора и скрам-мастера.

Вот так для сеошных или контентных задач:

Вот так классическая доска разработчиков с 1-2-недельным спринтом:

Подводя итоги.

Оставайтесь человеками по отношению к людям и не забывайте отдыхать.