Как решать проблемы с планированием в ИТ.
Из-за того, что в нашей сфере мы почти не занимаемся выпуском полностью одинаковых стандартизированных продуктов, степень неопределенности при производстве достаточно высока и очень разнится от компании к компании. Поэтому существует заблуждение, что качественно и точно планировать разработку инновационных решений невозможно. Это удобное убеждение для многих участников процесса: оно открывает неограниченный простор для творчества и снимает ответственность за результат.
Однако если вы тот, кто финансирует разработку, вы наверняка хотите знать, когда вы начнете получать от нее отдачу. Выпуск продукта на рынок часто связан с сезонностью, а еще требует подготовки, проведения маркетинговой кампании и прочих трудоемких и дорогих операций, которые полностью зависят от выполнения командой разработки плана.
Предсказуемость крайне важна и при работе с клиентами. Пока вы стартап с уникальным предложением, вас, возможно, и готовы ждать неограниченное количество времени, но в условиях конкуренции крупные компании выберут стабильность результата: им нужно планировать свои бюджеты, и есть большая разница между тем, чтобы ждать функциональность, скажем, 3 месяца, и «мы исследуем вашу проблему и дадим вам знать, как только решим ее».
Идеальный партнер для любого бизнеса тот, кто может сходу сказать, когда будет готово то, что бизнесу нужно и выполнить задачу точно в срок.
Я считаю, что причины возникновения проблем с планированием и выполнением плана всегда лежат в области управленческих компетенций и никак не связаны со степенью инновационности или необычности бизнеса.
Как правило, они вызваны одним или сразу несколькими из описанных ниже факторов.
1. Некачественно проведенный этап подготовки, анализа и описания задач.
Признаки:
- систематическое возвращение задач из разработки в анализ или из тестирования в доработку;
- постоянное увеличение скоупа (размера функциональности) в процессе разработки;
- постоянная недооценка задач со стороны девелопмента;
- постоянные конфликты между продуктовиками и разработчиками.
Как починить.
1. Нужно разработать и внедрить критерии приемки задачи в разработку. Инициатива должна исходить от команды разработки. Среди критериев обязательно должны быть:
- бизнес-цель задачи;
- необходимые артефакты, позволяющие инженерам делать полный анализ задачи и видеть ее масштабы;
- описание ограничений и допущений;
- описание того, что не входит в задачу.
2. Убедиться, что в каждой команде есть человек, который владеет компетенциями бизнес-аналитика: умеет продумать задачу со всех сторон и описать ее структурно, используя одну или несколько подходящих нотаций (UML, BPMN, IDEF и т.п.). Разработчики при этом должны уметь читать диаграммы. Нельзя описывать задачи текстом, его трудно воспринимать, из-за чего постоянно возникают проблемы с деталями, которые могут кардинально менять смысл задачи!
3. Убедиться, что у вас есть родмап (Roadmap)=план как минимум на квартал вперед и что команды о нем знают.
4. Внедрить процесс обсуждения вариантов реализации с разработчиками до принятия окончательного решения о включении функциональности в план (варианты из scrum: pre-refinement и refinement).
2. Неумение (иногда — нежелание) технической команды оценивать разработку того, что раньше не делали.
Эта проблема может быть никак не связана с разработчиками. Ее причиной бывает и некачественное описание задач, и постоянно вылезающие неучтенные вещи (см п. 1). Из-за этого девелоперы понимают, что оценки не имеют никакого смысла и не хотят их давать потому что их демотивирует регулярное заваливание сроков.
Еще одной причиной может быть неправильное управление людьми, например, когда за ошибку разработчика наказывают в любой форме или когда неумение оценивать и попадать в свои оценки не учитывается при повышении уровня сеньорности и, соответственно, уровня оплаты труда.
Признаки:
- отказ от оценки («начнем — разберемся…», «ну, тут невозможно сказать…»).
Как починить.
1. Внедрить все, что описано в п.1.
2. Развить у инженеров привычку давать оценки. Нужно принять тот факт, что сначала эти оценки будут очень неточными и помогать улучшать их качество на основе исторических данных. Для этого важно настроить систему управления задачами (например, Jira) так, чтобы по ней можно было собирать статистику.
А именно:
- ввести корректные, подходящие вам типы задач, по которым вы хотите собирать данные (например, отделять новые фичи, баги, исследования и т.д.);
- ввести правильные статусы для задач (минимально возможное количество);
- ввести правила перехода задач из статуса в статус и другие полезные правила;
- ввести подходящие вам этапы разработки (не обязательно это должны быть 2х-недельные спринты).
Очень важно убедиться, что команды разработки понимают ценность исторических данных и не тратят слишком много времени на заполнение трекера. Современные системы типа Jira при правильной настройке требуют минимального количества действий со стороны инженеров.
Хорошо настроенная система управления задачами позволяет иметь адаптивный процесс управления проектами, при котором точность оценки регулируются поправочными коэффициентами (например, мы знаем, что Петя обычно дает оценку с точностью в +-20%, и чаще всего это +20%) на основе исторических данных. По таким системам менеджер может предсказывать даты выпуска продукта лучше, чем сами команды, а так же строить систему мотивации.
3. Сделать попадание в план важной частью ОКР (или KPI) и связать это с вознаграждением.
4. Дать команде возможность участвовать в процессе улучшений. Как показывает практика, люди прекрасно знают, как решать проблему, если им: а) показать ее и б) объяснить почему она важна.
3. Неизвестное количество важных изменений, которые потребуется внести в уже разработанное.
Этот пункт обычно страшно демотивирует инженеров, которым приходится выбрасывать часть своего труда в мусорку или ставить в код «костыли» не из-за собственных ошибок при построении архитектуры, а из-за того, что «кто-то не мог нормально продумать функциональность». Однако, в отличает от п 1, проблема тут не в описании конкретных задач, а в изменениях в продукте в целом. И часто эти изменения неизбежны из-за особенностей бизнеса.
Признаки:
- переделки уже разработанного на завершающих этапах работы.
Как починить.
1. Разработать и внедрить базовые требования к выпускаемому продукту и со стороны бизнеса, и со стороны технической команды. Эти требования должны быть по умолчанию выполнены везде.
2. Адаптировать методологию ведения проекта под реальность. Для этого тоже важны исторические данные.
Например в игровой индустрии продуктовик чаще всего не может точно сказать, хороша ли задизайненная им игра, не взглянув на нее в собранном виде: когда картинка и механика соединены. Соответственно, после того, как он посмотрит и почувствует динамику, он может захотеть поменять вообще все и разработчику придется выбросить большую часть своей работы. Вместо того, чтобы воевать с бизнесом, есть смысл договориться про минимальный набор функций, которого будет достаточно для первичной, а потом и вторичной и т.д. оценки. Так обратная связь придет в команду до того, как переделывать нужно будет уже слишком много, но и тогда, когда можно будет реально оценить то, что получается из продукта. То есть, мы можем сказать, что итерация №1 включает в себя функции 1, 2, 3 и продлится 2 месяца. После этого продукт уходит на ревью, пересматривается дизайн и разработка дальше продолжается по итерациям длиной, например, в 2 недели.
4. Непредсказуемые срочные и важные задачи, которые сдвигают выполнение основной работы.
Откуда могут приходить такие задачи:
- от бизнеса;
- от поддержки;
- от других команд (взаимосвязанная разработка).
Признаки:
- постоянная остановка задач, их простой в ожидании;
- невыполнение целей спринта (если работа по scrum).
Как починить.
1. Разделить задачи на срочные и несрочные, установить SLA (service-level agreement) — максимальные сроки ожидания и максимальные сроки выполнения — для каждого типа задач.
2. На основе исторических данных (если их пока нет, то методом угадайки и адаптации) установить временные квоты на задачи, приходящие из поддержки (или из других команд). Например: 20% времени спринта команда занимается поддержкой, поэтому мы планируем только 80% времени. Если задач из поддержки нет, то это время тратится на что-то другое по договоренности.
3. Или ввести дежурных по поддержке. Это может быть нужно тогда, когда помимо самих задач, люди тратят много времени на помощь работникам службы поддержки в ответах на вопросы клиентов. Тогда мы знаем, 1 человек из команды всегда на 100% занят такими проблемами и планируем работу с учетом этого. А ребята из поддержки всегда знают, к кому обратиться сегодня и не дергают всех подряд членов команды.
Часто проблемы, связанные с планированием пытаются решить через смену методологии управления проектом, например, со scrum на kanban. Однако по факту нет никакой разницы, какими способами вы руководите процессом, функции менеджмента от этого не меняются и не исчезают.
Планирование и преодоление связанных с ним трудностей — важная обязанность руководителя в любом бизнесе, потому что результат отпущенного на самотек процесса редко бывает оптимальным с точки зрения соотношения затрат и ценности.
Вам будет интересно почитать: Алгоритм решения проблем в управлении отделом разработки ПО.
Консультант, директор по разработке.
Умею делать эффективных менеджеров из инженеров и решать любые проблемы в области управления разработкой.
