[Из песочницы] Гибкие методологии: взгляд со стороны бизнеса (часть 1)
Подавляющее большинство из нас прекрасно знакомы с гибкими методологиями разработки, читали agile-манифест, работали по scrum или kanban. Некоторые — успешно внедряют в своих отделах те или иные agile-практики, иные — пропагандируют отказ от них в пользу других методологий. В общем, тема не нова, хорошо знакома и изрядно заезжена.
Однако большинство публикаций посвящены лишь внешней стороне вопроса, где даются именно те ответы, которые психологически мотивируют исполнителей принять «agile», но очень мало предоставляется информации о том, зачем же это нужно бизнесу (или же, что хуже, пользу для бизнеса пытаются вывести из предназначенных для сотрудников лозунгов).
Являясь сам большим поклонником использования гибких методологий разработки (а, скорее, отдельных практик, подходящих для конкретного бизнеса), я все же хотел бы предложить Вам посмотреть на них под не совсем привычным углом. Опытные руководители вряд ли встретят в этом цикле статей что-либо новое, а всем остальным — добро пожаловать под кат.
Цикл посвящен не какой-то одной конкретной методологии, а рассказывает о решении проблем бизнеса с помощью гибких методологий в целом, поэтому в тексте будут смешаны и постулаты agile-манифеста, и артефакты скрама, и практики канбана без претензий на полноту. Ко всему прочему речь пойдет исключительно в контексте разработки ПО. Последовательность, в которой будут разобраны те или иные элементы, зависит, в первую очередь, от масштаба той проблемы, которую решают описанные практики. Безусловно, каждая из них призвана решить не одну возникающую перед бизнесом проблему, а целый комплекс задач, но для простоты каждая будет соотноситься в статье с одной основной проблемой. Итак, начнем.
- Люди и взаимодействие важнее процессов и инструментов
- Работа короткими итерациями
- Готовность к изменениям важнее следования первоначальному плану
Люди и взаимодействие важнее процессов и инструментов
Первый постулат agile-манифеста, трактуемый совершенно противоположно исполнителями и бизнесом. И не просто так он вынесен именно на лидирующую, открывающую сам манифест позицию — именно за ним стоит одна из самых разрушительных для бизнеса «болей».
Проблема
При разработке сложного продукта, которым, безусловно, является программное обеспечение, сотрудник, разрабатывающий фрагмент системы или же некий критический функционал, становится обладателем уникальной экспертизы, единственным носителем ценнейшего для компании опыта, а при относительно долгой работе — незаменимой «звездой» в рамках отдельно взятой компании. И мало что для бизнеса есть страшнее, чем зависимость от отдельно взятого сотрудника.
Чтобы это произошло, сотруднику вовсе не обязательно сознательно и злонамеренно «завязывать» на себе часть процессов, а в дальнейшем вступать в торги. Зачастую бизнесу достаточно некоторое время следовать «классической» схеме распределения ролей в команде. Подобная ситуация несет большую угрозу для бизнеса как при неизбежном уходе «звезды» по решению одной из сторон, так и при начале «звездной болезни» у осознавшего свою (впрочем, иногда совершенно невостребованную на рынке) компетентность сотрудника.
Решение
Любыми доступными и подходящими способами «размазать» ответственный участок работ между несколькими исполнителями, а также «извлечь» необходимый багаж знаний в любой тиражируемой форме. Для этого подойдет работа в кросс-функциональных командах, регулярное проведение ретроспектив, ведение базы знаний, организация внутренних конференций и так далее. Все зависит от размера компании, доступных инструментов и личных пристрастий.
Достигнутая цель
Взаимозаменяемость сотрудников, возможность дублирования функциональных обязанностей и устранение точки отказа в лице единственного носителя специфического опыта, сбор и систематизация необходимых знаний в единый «реестр» с возможностью быстрого ввода в проекты нового игрока, возможность относительно безболезненной ротации кадров.
Мотивация разработчиков
Схема строится на удовлетворении у сотрудников чувства собственной важности, для чего используются старые и хорошо зарекомендовавшие себя психологические методы.
Для команд будет взращиваться идея работы в самостоятельной, способной решить полный спектр задач «боевой единице», которая, в случае чего может и поспорить с бизнесом. Здесь бизнесу важно, не отклоняясь от курса, периодически принимать идеи команды в мелочах. Например, приветствовать возможность выбирать стек разработки, одобрять некритичные решения по функционалу или дизайну ПО и так далее. Необходимо дать людям веру, что их мнение ценят и слышат, а также поддерживать их убежденность в автономности собственной работы. В этом случае каждый из сотрудников будет вовлечен в работу группы на достаточном уровне, чтобы сохранять знания.
Разбор принятых технических решений и возникших сложностей на регулярных ретроспективах позволит команде представлять происходящее на соседних участках и при необходимости включиться в работу, а исполнителю усложнит возможность утаить важные нюансы. Также это позволяет в определенных пределах повысить качество разрабатываемого решения. Еще одной важной целью является точечная групповая диагностика, позволяющая понять особенности происходящего группового процесса и скорректировать его, направив энергию сотрудников в нужное русло. Впрочем, разработчики в массе своей ретроспективы очень не любят, и крайне важно организовать их таким образом, чтобы происходящее не было для сотрудника стрессовым фактором. Это мероприятие может быть для них очень мотивирующим и вдохновляющим, если проводить его в максимально позитивном ключе, начиная встречу, при возможности, с транслирования руководителем энтузиазма и гордости за проделанную командой работу. Главное — чтобы люди охотно делились друг с другом деталями.
Внутренние конференции могут позволить себе только крупные игроки, но они дают разработчикам возможность блеснуть профессионализмом перед своими коллегами и почувствовать себя оцененными по достоинству. Для компаний с небольшим количеством разработчиков в 10–20 человек отлично подходит организация внутренних «курсов» по смежным дисциплинам, на которых, например, фронтенд-разработчик может прочитать несколько лекций по vue.js для своих коллег, программирующих бекенд на .net core. «Преподаватель» в этом случае сможет удовлетворить свою потребность в признании, «студенты» получают возможность профессионально расти и пробовать новое, а бизнес вдобавок к возросшей вовлеченности сотрудников совершенно бесплатно получает более квалифицированные кадры, знакомые притом с не затрагивавшими их раньше аспектами работы.
Ведение внутренней базы знаний — сложная и требующая времени задача, а полнота информации зависит исключительно от вовлеченности участвующих в ее дополнении. Актуальная база знаний не может быть заполнена в директивном порядке, и самый действенный вариант — сделать актуализацию данных почетной. Для этого подойдет использование «внутренней валюты» (условных звездочек-наград, которые можно на что-то обменять), публичная похвала («Вася 2 месяца назад по твоему вопросу все очень здорово описал, посмотри в wiki»). Основное — участвующие в ведении базы знаний сотрудники должен быть убеждены, что их ценность для компании от этого растет.
Критика
Идея командного взаимодействия низводится до формальностей с проведением постоянных и не несущих большой ценности совещаний, а время, которое можно было бы потратить на реальный прогресс в решении инженерных задач, расходуется на следование ненужным ритуалам. Обязательность указанных мероприятий ведет к микроменеджменту со стороны руководства и негативно сказывается на мотивации самых талантливых сотрудников.
Защита
От проведения ретроспектив или обмена знаниями сотрудник будет демотивирован лишь в одном случае — если будет чувствовать угрозу из-за подобных практик. Если продемонстрировать процесс как возможность глубже вникнуть в работу компании, профессионально вырасти, следить за прогрессом развития продукта и непосредственно влиять на него, то мотивация будет только расти. Бизнес же получает снижение рисков за счет большей прозрачности в отношении технических деталей.
Работа короткими итерациями
Безусловно, это одна из первых практик, с разбора которой следует начать, как с одной из наиболее известных и максимально распространенных, без которой тяжело представить себе гибкие методологии как таковые. Идея работы короткими циклами настолько прочно ассоциируется с условным «agile», что некоторые даже ставят между ними знак равенства.
Проблема
Со стороны бизнеса разработка ПО всегда была тяжело прогнозируема. Еще 20 лет назад любой названный срок разработки было принято умножать на 1.5, однако и подобный допуск часто оказывался недостаточным. Еще большей проблемой всегда являлось то, что для человека без технической экспертизы совершенно не представляется возможным узнать реальный статус выполнения проекта, а полагаться в этом отношении на голословные утверждения не всегда разумно.
Разработчики с трудом оценивают сроки по разным причинам. Иногда это может быть работа над действительно непредсказуемым участком, например, над требующим творческого подхода решением проблемы, или же над сложным алгоритмом. Однако гораздо чаще встречаются ситуации, когда разработчик хочет сделать идеальное, по его представлению, или же обобщенное решение, которое бизнесу абсолютно не нужно, а стоит дорого.
Необходимо иметь четкий прогноз: в какой срок и за какую сумму бизнес получит ожидаемый и измеримый результат, ведь без этих цифр до завтрашнего дня он может элементарно не дожить.
Решение
Раздробить работу на короткие промежутки, где в конце каждого этапа сотрудники обязаны предъявить минимальный жизнеспособный продукт, пусть с небольшим, но доказанно работающим готовым функционалом. Это должна быть именно работающая программа (сервис, приложение, сайт), готовая к тиражированию. «Сферические алгоритмы в вакууме» и приложения, запускающиеся только на машине разработчика, не допускаются, приравниваясь к невыполненной работе. На каждой итерации требуется именно готовый продукт.
Достигнутая цель
Объективный контроль сроков и результата выполнения работ. Гарантия, что вектор усилий команды направлен именно на реализацию готового решения, а не на разнообразные технические «улучшения». Четкая измеримость израсходованного и прогнозируемость необходимого бюджета. Возможность внесения корректив в процессе работы.
Мотивация разработчиков
Мотивация строится на догме «поступательное движение к цели», для чего важно сместить фокус внимания программистов с процесса разработки на результат, в качестве которого выступает работающее ПО. Убедить разработчиков ценить не технические детали реализации, а появление у продукта новых свойств.
Для самых проактивных сотрудников достаточным может оказаться всего лишь раскрытие части плана развития продукта, которое даст им краткосрочное понимание целей разработки на несколько итераций вперед. Для других же работников потребуются объяснения, почему именно эта стратегия выигрышна стратегически, однако принцип один и тот же: приобщить команду к глобальной цели и дать ощущение удовлетворения от ее постепенного достижения.
Критика
Разработка в рамках узких временных окон с необходимостью обеспечить работу нового функционала как части системы в целом приводит к крайне низкому качеству кодовой базы, а разработчики вынуждены в угоду скорости перестать писать качественные и валидированые решения, программируя по принципу «работает и ладно».
Защита
Результат в целом оказывается выше ожиданий при разумной работе линейного менеджера (лида), который будет контролировать качество исполнения и архитектуру решения, отвечая за качество. Потенциальные слабые места должны быть своевременно задокументированы как «технический долг» для дальнейшего устранения, приоритетом же должна быть скорость и прогнозируемость результата.
Готовность к изменениям важнее следования первоначальному плану
Один из постулатов agile-манифеста, неразрывно связанный с упомянутой выше работой короткими итерациями.
Проблема
Современный мир крайне динамичен. Продуктовая компания вынуждена постоянно тестировать гипотезы как для наиболее четкого попадания в удовлетворение спроса своей целевой аудитории, так и для совершения «разворотов» (pivots), при которых претерпевает изменения сама идея продукта. Более того, в цикле развития продуктовой компании нередка ситуация, когда в результате исследования спроса и анализа фидбека продукт, разрабатывавшийся на уровне прототипа для одного рынка, «выстреливает» и начинает успешно решать схожую задачу на другом, что требует новых изменений.
Возможность быстрого тестирования гипотез — одно из ключевых преимуществ, которые позволяют маленькому и гордому стартапу обогнать крупную компанию, неповоротливую по своей структуре, хотя и готовую к масштабным финансовым вливаниям.
Аутсорсинговая компания постоянно сталкивается с противоречивыми требованиями клиентов, которые необходимо удовлетворять, часто — для самой возможности дальнейшего сотрудничества.
Решение
Разработчиков необходимо настроить на гибкость происходящих процессов, дать им ощущение «драйва» от новых вызовов без сожалений о «недоделанной» работе.
Достигнутая цель
Возможность быстрых и максимально «дешевых» изменений продукта и ПО.
Мотивация разработчиков
Основополагающими являются два принципа.
Во-первых, необходимо внедрить мысль о том, что гибкость — в самой основе природы. Подобно живым организмам, постепенно мутирующим для приспособления к условиям среды, продукт должен меняться, приспосабливаясь и реагируя на поступающие извне сигналы.
Во-вторых, у сотрудников должна быть реализована потребность в безопасности. Любые новые (часто противоречивые) требования заставляют многих испытывать стресс, чувствовать личную ответственность за то, что реализованные фрагменты системы оказались не нужны, или же чувство вины за якобы плохо сделанную работу. Это крайне опасно для микроклимата в коллективе и ведет к снижению производительности труда, мотивации, а иногда даже способно развалить команду. Чтобы ни в коем случае не допустить падения «боевого духа», крайне важно каждое изменение позиционировать как новый вызов и возможность.
Критика
Отсутствие внятного плана развития ПО вкупе с возможностью выставлять идущие вразрез с имеющимся продуктом требования ведут к регулярным авралам и глобальному рефакторингу с непредсказуемым результатом при каждой «спорной» итерации.
Защита
Возможность осуществления «быстрых» изменений позволяет приспосабливаться к меняющимся требованиям рынка, а при грамотно выстроенном процессе разработки и возможности повторного использования кода масштабное «переписывание» не потребуется. Относительно «дешевые» развороты — гарантия продвижения вперед, ради чего можно в разумных пределах пожертвовать организованностью процесса.
P.S. На этом я заканчиваю первую статью цикла и буду благодарен за Ваши отзывы, конструктивную критику и обмен опытом в комментариях.
