Сегодня в моем блоге история на стыке проектного управления и спортивных метафор от одного моего знакомого ИТ-шника со стажем. Он из тех, кто не умеет просто “делать таски из Jira”. Он копает глубже: что за проблему мы решаем, кому это нужно и почему система устроена так. Недавно он пришел ко мне на кухню с неожиданной, но на мой взгляд, очень интересной идеей: возможно, на парадигму управления проектами, которую исповедует человек, влияет спорт, которым он занимался в детстве.
Да, звучит как теория из TEDx районного ДК. Но мысль-то очень интересная. Так не без некоторой самоиронии он объяснил, почему на одном из последних проектов ему не подошел классический подход к командной работе в ИТ “как будто от профессионального борца”.
Сам он в детстве играл в футбол. Это было не просто про “побегать за мячиком”. Скорее про видение поля, понимание ролей, взаимную подстраховку, умение вовремя передать пас, ответственность за общий результат и способность действовать вне своей формальной роли, если того требует ситуация. А именно этого на том проекте в итоге и не хватало.
Продолжу метафору уже его словами, несколько изменив контекст…
Итак, поговорим на примере одного проекта. Как это водится, никаких имен, явок и паролей. Все совпадения с реальными персонажами случайны, а обстоятельства - выдуманы.
“Командная” разработка на проекте N
Предположим, на проекте N мы строили все, отталкиваясь от понятия жизненного цикла разработки программного обеспечения (Software Development Life Cycle, SDLC). Все вполне детерминировано: сначала с эпиком работают аналитики, потом дизайнеры, затем разработчики делают отдельные задачки, а дальше - тестировщики их тестируют. После них - деплой и эксплуатация. Красиво и логично - примерно как диаграмма в презентации для инвесторов.
Проблема обнаружилась не в этапах как таковых, а в том, как люди взаимодействовали внутри этой схемы. Настоящая командная работа была только на диаграмме в PowerPoint. На деле же проект N был конвейером - последовательной передачей задачек от одного к другому. Аналитик что-то формализовал и передает дизайнеру. А после разработчика приходит тестировщик и все проверяет. Если попадается большая задачка, ее пилят на несколько разработчиков, а потом каждый блок тестирует свой тестировщик. В итоге все существуют как будто в вакууме - в отрыве от общего контекста.
Иногда этот вакуум даже бережно охраняется как личное пространство ответственности. Адепты подобного подхода на собеседованиях потом так и говорят: “Я хочу просто брать задачки из Jira и последовательно их выполнять. Не хочу куда-то лезть и с чем-то разбираться; поставьте мне задачу и все сделаю”.
В общем, классический waterfall, при том что руководство проектом уверяло всех, что у нас гибкие методологии, и даже безуспешно пыталось натянуть это на канонический SCRUM. Видимо, под гибкостью-итеративностью понималось то, что нам постоянно приходилось что-то переделывать.
Если искать спортивную аналогию, то это эстафета. Тебе выдали палочку - беги, пока не передашь следующему. Каждый отвечает за свой этап. Предположим, на каком-то этапе произойдет провал. Если повезет, его “вытянет” следующий. А если на предыдущем этапе сформировалась фора, то свой этап вообще можно проскочить на шару.
Эстафета не относится к командным видам спорта. А в разработке у этой эстафеты еще и соперников нет. Вы просто бежите в заданную точку за какое-то время. Причем, контрольные сроки тоже никто до секунды не сверяет - нет установленных за ориентир рекордов мира, страны, поселка. Каждая задача уникальна и никто не будет сравнивать, что предыдущую реализовали за 12 дней, а эту за 13. Сроки заявляют, но чаще не укладываются, и это норма жизни (см. Закон Хофштадтера). Участники бегут в своем темпе, как получится. Каждому из них в разумных рамках все равно, за сколько они закончат дистанцию. Лишь бы соблюдался административный дедлайн.
Похоже на конвейер. Он хорош при массовом производстве для ускорения. Но на штучном товаре (коим и является разработка ПО) его преимущества сомнительны.
Ищем “командность” в спорте
Возможно, для тех, кто в детстве занимался какой-нибудь борьбой, эстафета действительно выглядит командной. В борьбе ты вообще сам за себя: пришел и либо выиграл свою схватку, либо нет. Если победа под вопросом, извернулся и из последних сил вырвал ее буквально зубами у соперника (даже если ситуация казалась безнадежной), то есть решил проблему методом грубой силы. Все зависит только от тебя. О команде вспоминают только на каком-нибудь рейтинге по количеству побед за сезон.
И вот борцы собираются в команду и начинают играть в эстафету. Если сравнивать с борьбой, то да, эстафета - это как минимум наличие какой-то команды, цепочки для передачи. Однако в ней все равно каждый играет сам за себя. Пробежал хорошо - молодец. Если пробежал плохо и все проиграли, тебя, конечно, осудят. Но вот если пробежал плохо, а несмотря на это, команда выиграла, медали все получат одинаковые.
А вот тот же футбол построен совершенно иначе. Это не "22 бугая бегают за одним мячиком", как многие думают. Там предусмотрены свои роли: вратарь, полузащитники, защитники, нападающие. Хотя обычно в массовой культуре интеллект футболистов не жалуют, сам спорт очень интеллектуальный (в определенных границах).
Последовательной эстафете не хватает главного - общения разных ролей. В футболе у игроков есть свои амплуа, но никто не мешает защитнику или вратарю забить гол. Это не запрещено и даже наоборот, если вратарь забьет гол сопернику, это будет настоящим событием. А в определенные моменты игры нападающие могут подтягиваться к собственным воротам, чтобы помочь защитникам, если на них сильно давят.
В отличие от легкоатлетов в эстафете, футболистов учат в принципе передавать пас (как вперед, так и назад). И это не просто про формальную передачу палочки-мяча. Это про видение ситуации на поле. Если напарник по команде в более выгодной ситуации, не нужно ломиться к воротам соперника самому. Вовремя отдать пас - увеличить шансы на успех команды (пусть, может, и не получить свою каплю славы).
Все друг друга могут заменить, но включаются в чужую работу, только если действительно надо, не забывая свое про основное амплуа, конечно же.
Команда планирует свои совместные действия. Например, если у соперников в команде есть звездный нападающий, тренер выбирает защитника, который будет играть только на эту звезду. На ближайший матч это будет его персональная зона ответственности. Фактически, у него есть ТЗ: “Держать нападающего”. Но он все еще будет включен в общий процесс игры в качестве “защитника общего профиля”.
Индивидуальное мастерство никто не отменял. Но вне зависимости от ампула, футболист должен в каждый момент матча видеть все поле, понимать, где находятся свои и чужие, куда нужно сейчас бежать, чтобы закрыть потенциальную дыру в защите, или куда передать пас. Нужно предвидеть развитие ситуации - где стоит мой нападающий и чужие защитники, куда они все побегут, если я попытаюсь передать пас нападающему и поймет ли он эту задумку. Иными словами, надо действовать на благо общего проекта (в данном случае - забивания гола или защиты своих ворот), не обсуждая, что “в задаче этого не написано”. А теперь оцените количество связей и обрабатываемой футболистом информации, если на поле таких как ты еще 10 из твоей команды и 11 из команды соперника, и все постоянно двигаются. Это сложно.
Другая командность
Возвращаясь обратно к взаимодействию в ИТ и пытаясь применить к команде именно “футбольную” схему работы, нам нужны программисты, которые умеют в аналитику, тестирование, но главное в бизнес - понимают, какую вообще задачу сейчас решают, кому и зачем это нужно. Аналогично мы получаем аналитиков, которые понимают, что мы можем технически и главное какой ценой всех прочих ролей.
Из-за отсутствия этого в схеме с эстафетой часто закрадывается испорченный телефон: перед началом своей части работы каждый читает задачу и выполняет так, как понял - буквально. Это “как понял” отличается от оригинала тем больше, чем хуже участник “эстафеты” представляет себе полную картину. К моменту, когда ТЗ дошло до тестирования, первоначальная задумка может оказаться существенно искаженной.
Приведу пример из жизни.
Для крупного заказчика мы делали некую систему. Пользователь должен иметь возможность авторизоваться в интерфейсе и видеть свои транзакции. Проверяя код за коллегой, я обнаружил факап: судя по коду, залогиненный пользователь мог видеть не только свои транзакции, а вообще все - от всех пользователей системы. Их даже можно было фильтровать по полям - ФИО и т.п.
Я понимаю, что аналитики, вероятно, подумали, что видеть только свои транзакции - это очевидное требование, и не написали об этом явно. Но разработчик сделал строго как написано, считая, что он не должен ни за кого думать. Он мог бы это как-то критически переосмыслить или хотя бы задать вопрос аналитикам (хотя что тут спрашивать), но не стал. Когда я спросил его, почему он не сделал очевидный фильтр по текущему пользователю, тот ответил фразой "а у меня этого в задаче не было написано". И если даже формально он прав, в тот момент я понял, насколько по-разному мы понимаем границы ответственности - представил наши репутационные потери, если бы это все доехало до прода и вернулось бы в виде бага от заказчика или возмущенных пользователей. Ну и ценность этого разработчика в моих глазах в тот момент сильно упала. Если человек этот замысел не понял, не хочет понимать и вообще делает все строго по промту, не задумываясь о смысле и контексте, чем он отличается от нейросети?
А что зацепило лично меня
Я вижу какое-то движение на рынке труда от конвейера с узкими функциями к мультикомпетентности. При наличии основной компетенции поощряется включение критического мышления по смежным направлениям. Мне комфортно работать в таких командах и организовывать по этому принципу свои в качестве тимлида.
В этом месте мне обычно возражают, мол нам просто нужны программисты, которые будут “делать объем”. Но на деле при таком подходе к разработчикам как к землекопам (про полтора землекопа знаете же?) существенно возрастает нагрузка на других участников команды - тех, кто должен сначала все разжевать, а потом отревьюить. Проект в итоге очень быстро превращается в некоего Франкенштейна, ибо тот, кто делает ревью, зачастую стоит перед выбором - принять код как есть или отклонить и сорвать дедлайны. Нанимать “дешевых” программистов на самом деле обходится очень дорого.
Возможно, проблема заключается в том, что на разработку ПО часто смотрят как на ПРОЦЕСС в буквальном смысле слова - как на последовательность функций (наличие сложного workflow в Jira может усиливать это заблуждение), хотя на самом деле это ПРОЕКТ, а там совершенно другие типы связей между участниками. Не последовательные - от одной функции к другой (как в эстафете), а комбинаторные, как в футболе. Для успеха проекта каждый участник должен чувствовать и проявлять некоторую разумную долю ownership. Это должно быть одним из значимых элементов внутренней мотивации.
Но как позиционировать вакансию в команде (или самого себя) на рынке труда? Как сепарировать себя от массы тех, кто нанимает землекопов и тех, кто только мечтает землекопом стать?
Кто-то скажет, ты просто не на своем месте, тебе надо руководить. Кем? Землекопами? Было, спасибо. Обозвать вакансию или себя инженером? Максимально размыто, в нашей стране ни один эйчар не поймет, что ты имеешь в виду. Или просто надо искать команду, где играют в твой вид спорта?
Что почитать
Очевидно, с проектами “везло” не только мне. Примерно об этом нашел рассуждения в книгах:
Shape Up от создателей Basecamp (в свое время они прославились книгой про идеологию удаленки - Rework). Рвет все классические шаблоны (как и остальные их книги) управления проектами.
Domain Driven Design - бестселлер Эрика Эванса.
Вот несколько цитат из них:
Разделять проект на задачи заранее — всё равно что запихнуть презентацию в шредер. У каждого будет только свой кусок. Наша цель — всегда иметь перед глазами проект целиком, чтобы у всех была общая картина.
Страшнее всего отделить анализ проблемы от проектирования архитектуры. При этом между двумя процессами не происходит обмен полезными знаниями и выводами, полученными в результате выполнения каждого из них.
Разработку программного обеспечения принято метафорически сравнивать с процессом фабричного производства. В этой метафоре скрыта одна неявная посылка: высококвалифицированные инженеры проектируют и конструируют, а менее квалифицированные рабочие собирают продукцию. Эта метафора загубила множество программных проектов по одной простой причине: разработка программ целиком состоит из проектирования/конструирования. Во всех группах разработчиков есть распределение по специализированным ролям, но слишком резкое разделение ответственности за анализ, моделирование, проектирование и программирование вступает в противоречие с принципом ПРОЕКТИРОВАНИЯ ПО МОДЕЛИ (MODEL- DRIVEN DESIGN).
