Всем привет! Сегодня я хотел поговорить о процессах разработки.
По мере роста компании развивается не только сам бизнес, но и внутри компании накапливаются проблемы, в частности в процессе развития.
Зачастую их пытаются решить путем внедрения каких-то практик и новомодных методологий.
Увы, эта вынужденная перестройка процесса по книгам и тренингам часто приводит к еще большим проблемам – издевательствам над людьми.
Недавно я выступал на конференции Saint TeamLead Conf 2019 , в докладе я рассказал о том, как мне удалось обнаружить ряд проблем в рабочем процессе и затем постепенно их преодолеть.
Здесь я попытаюсь описать наиболее ценные практики, которые помогли мне не только улучшить рабочий процесс, но и перестать издеваться над разработчиками.
Изменилось отношение сотрудников к компании в целом и рабочему процессу.
Проблемы процесса разработки
Итак, когда готовые подходы не дали результатов и мы были близки к отчаянию, я начал анализировать процессы и начал всё разбирать.В результате получается следующий список проблем:
- Доска перегружена задачами — там царил настоящий хаос.
Глядя на плату, понять происходящие процессы было практически невозможно.
- Не было нормальных оценок.
— мы не умели правильно оценивать задачи по срокам выполнения, из-за этого сроки постоянно переносились, бизнес-менеджеры мешали разработке.
- Постоянно срывают сроки — мы не могли точно сказать, когда эта функция выйдет в производство; чаще всего его выкатывали гораздо позже запланированного из-за внешних факторов, например, прибегал бизнес и просил быстро сделать сначала какую-то срочную фичу.
- Не было понимания, как ускорить разработку — наем новых людей и загрузка инженеров на 100% не всегда ускоряют процесс.
- Планирование и неотложные задачи — если с текущими задачами можно было как-то строить планы и обозначать примерные сроки, то срочные задачи, которые обычно приходили из бизнеса, ломали все планы.
- Встречи занимают много времени - самая типичная наша ошибка: что-то не получается или надо расставить приоритеты в задачах - но давайте соберемся и обсудим.
Или обычные встречи, где разработчики сидели час-два и не понимали, что они там делают.
- Проблема мотивации и вовлеченности команды — зачастую руководство просто внедряло какие-то нововведения сверху, не спрашивая мнения команды разработчиков; это не улучшило атмосферу в команде.
Чтобы как-то выйти из этой ситуации, мы обратились к методу Канбан.
Что он нам говорит? Давайте улучшим то, что у нас уже есть.
Что ж, мы пошли улучшать наш процесс разработки.
Наведение порядка на доске
Мы стали рассуждать: если бэкендеры выполнили свою задачу и передали ее фронтендерам, они сразу начнут над ней работать? Глядя на доску, непонятно.Согласно принципам Канбана, мы разделили каждое направление разработки (их у нас было 5: бэкенд, фронтенд, DevOps, QA и дизайн) на две колонки: Делать и Готово.
Проблема сразу стала ясна: наша пропускная способность не позволяет нам выполнять столько задач, сколько от нас хотят. 
Канбан тоже говорит: давайте войдём WIP-лимит и ограничить количество задач.
Как мы определили пределы? Ээмпирически.
Мы, конечно, пару раз промахнулись, но потом подобрали, чтобы в узком месте не скопились задачи.
WIP-лимит дополнительной прибыли — это триггер, который говорит о том, что как только у нас заберут задание, мы сможем взять следующее.
Это своего рода система вытягивания.
К чему это привело? Инженеры стали больше внимания уделять проблемам, ведь когда они не могут решить проблему, на нее ставится блокировщик.
Брать больше задач невозможно, так как существует лимит WIP, инженерам приходится ждать помощи для его решения.
Есть шанс остаться без заданий.
Когда мы стали детально рассматривать проблему возврата задач, оказалось, что все делают их по-разному, например, кто-то пишет тесты, а кто-то нет. Были правила на этот счет, но такие, которые были навязаны властями сверху.
Они не решили проблему разработчиков.
Мы ввели новые правила ( Определение готовности ), которые были интегрированы в плату.
Они могли действовать как по определенному столбцу, так и по типу карты.
Например, API требует, чтобы серверная часть документировала все методы и так далее.
Правила были доступны всем и видны на доске, а главное, они исходили от самих инженеров и решали их проблемы.
Если что-то не было сделано, инженер это видел и шёл делать.
Рейтинги задач
Мы не знали, как оценивать задачи по срокам, но Канбан говорит нам: «Никаких оценок».Что делать? Мы собрали статистику и построили такой график.
Это спектральная диаграмма зависимости количества задач от времени.
Мы начали его изучать и увидели на графике 3 вершины, которые соответствуют трем видам работы.
На основе этих видов разработаны классификация и критерии таких работ. Мы представили эти типы на доске задач, а затем по ходу дела добавили дополнительные правила для каждого из них.
Мы получили это: 
Мы договорились с заказчиком, то есть с бизнесом, о соглашении о качестве обслуживания (SLA).
К нам приходит менеджер и спрашивает: «Сколько времени вам понадобится, чтобы сделать эту фичуЭ» Мы не можем точно сказать, сколько времени потребуется на его выполнение, но можем сказать, сколько времени потребуется на выполнение целой партии таких задач.
В Scrum-покере не было необходимости, и мы перестали мучить людей вопросами о сроках.
Они просто посмотрели статистику и назвали бизнесу сроки.
Конечно, у этого подхода были и свои недостатки.
Например, это не работало с новыми типами задач, по которым у нас просто не было статистики.
Мы пробовали старые методы, но потом накопилось достаточно данных и эта проблема исчезла.
Потом мы столкнулись с тем, что некоторые задачи стали попадать в другие виды работ. Мы провели небольшое исследование и выяснили, что некоторые задачи выполняются гораздо быстрее, потому что бизнес что-то обещал своим партнерам и просил разработчиков сделать это срочно.
Наоборот, некоторые задачи оказались не столь важными и были отложены.
Итак, у нас были приоритеты, то есть соглашения по классам обслуживания (CoS), мы их вынесли на доску.
А чтобы бизнес не злоупотреблял этим и не придавал всем задачам повышенную срочность, были введены горизонтальные лимиты незавершенного производства.
Как ускорить разработку
Мы снова обратились к статистике трекера задач.Мы обнаружили, что многие задачи висят на доске в ожидании доработок, проверок или дополнительных данных, то есть поняли, что разработку можно ускорить.
Мы начали смотреть, сколько задач накапливалось, сколько простаивало, и обнаружили, что некоторые фичи разрабатываются за меньшее время, чем ждут принятия.
Мы решили установить день приёмки фичи и сократили время релиза задач.
А потом мы установили CD (Continious Delivery) и начали отправлять уведомления.
Стало ясно, что нам нужен инструмент для оценки наших улучшений.
Мы решили использовать накопительную блок-схему.
В двух словах, как это строится: каждому рабочему центру (столбцу на доске) присваиваем свой цвет, берем статистику о том, сколько элементов (задач) находится в столбце в единицу времени, и выводим ее на график, располагая их один под другим.
На графике ось X — время, ось Y — количество задач.
Чему мы научились из этого? Здесь легко увидеть время выполнения заказа (срок изготовления) — горизонтальная линия (ширина потока по оси X) начинается с формулировки задачи и доходит до стадии готовности.
Таким образом, здесь вы можете увидеть, как задача проходит все этапы разработки – линия пересекает все цвета, каждый из которых соответствует своему этапу.
А также общий WIP-предел платы — высота потока по оси Y. Как увеличить скорость разработки? Можно уменьшить WIP-лимит (то есть сделать поток на графике уже), а можно сделать так, чтобы наш поток, направленный от начала координат в правый верхний угол графика, стремился вверх еще сильнее (т.е.
, еще больше поднять направление потока вверх, уменьшить его угол относительно оси Y).
Чтобы направить поток вверх, можно внедрить какую-то новую практику, например реализовать Docker или создать удобную базу знаний.
Это не обязательно должна быть техническая инновация; новый подход к управлению также может иметь такой эффект. 
Таким образом, мы получили инструмент, который четко показывал, какие улучшения сработали, а какие нет.
Планирование с деловыми, срочными и бесполезными задачами
Планирование развития вместе с бизнесом было самой большой болью.Что мы сделали? Получив задачу от бизнеса, устроили встречу аналитика и разработчика, где ее декомпозировали, а разработчик предложил решения.
В результате мы поняли, сколько и каких ресурсов требует задача.
И только потом бизнес без нашего участия строил планы и подсчитывал, сколько фич мы сможем выпустить.
В Канбане это называется частота пополнения .
Условно говоря, мы выделяем слоты определенного размера, в соответствии с WIP-лимитами, куда можно размещать задачи.
Каждый слот может содержать только ограниченное количество задач.
По-другому этот метод называется «планирование стаканчиками».
Мы сделали простой инструмент для бизнеса (таблицу Excel), с помощью которой можно визуально планировать.
Менеджеры дрались между собой, спорили, чья задача важнее, а потом приходили к нам и сдавали задачи на разработку.
Поскольку у нас уже были ограничения, бизнес более внимательно относился к выбору задач, выбирая самые важные, а не заваливал нас всякой ерундой, которая приходила им в голову.
И еще большой плюс: они сами подбирали задачи, без нашего участия, не отвлекая разработчиков на собраниях; работали спокойно и не тратили время на совещания.
Мы также обратили внимание на проблему неотложных задач.
Мы начали анализировать статистику по ним и поняли, что эти задачи не столь актуальны.
Например, нам нужна акция на сезонную замену шин для автомобилистов.
Мы знаем, что это всегда происходит 2 раза в год. Поскольку они повторяются, давайте заранее зарезервируем для таких задач места на доске.
Если нет ничего срочного, возьмем из очереди еще одно задание и без работы не останемся.
В результате мы выяснили, что 60% срочных задач на самом деле не являются срочными.
Была еще одна проблема.
Мы часто видели функции, от которых бизнес потом отказался, поскольку они оказались бесполезными с точки зрения бизнеса.
Мы предложили компаниям создавать MVP-функции, которые требуют гораздо меньше времени, чем обычная разработка.
Обратная связь стала удаляться гораздо быстрее, и инженеры начали понимать, что это эксперименты.
Раньше, когда проделанная неделями работа выбрасывалась на помойку, они переживали, это отравляло им жизнь.
Мы начали тестировать таким образом 85% фич, что в итоге высвободило много времени, которое мы потом потратили на проверку гипотез на практике.
Они уже приносили компании деньги.
Также, если в процессе что-то пошло не так, заказчик фичи со стороны бизнеса мог внести изменения на раннем этапе, а не на протяжении всего цикла разработки.
В результате выявился факт, что не все идеи работают. А если они не работают, то и незачем их делать.
С тех пор разработчики перестали заниматься обезьяньей работой и занялись именно тем, что приносит компании деньги.
Встречи
Внесенные нами улучшения к тому времени уже устранили ряд бесполезных встреч.Больше дискуссий о расстановке приоритетов не было, так как мы отдали это бизнесу и тоже планировали без инженеров.
Также мы отказались от пятиминутных рейдов менеджеров с просьбой «быстро помочь».
Остаются только действительно необходимые встречи.
Также мы ввели правило, что теперь встречи назначаются на определенное время, чтобы каждый мог планировать свое расписание.
В результате все чаттерологические встречи были преобразованы в следующие типы встреч:
- когда аналитик хочет обсудить с инженером конкретную проблему, например, чтобы найти оптимальное решение или декомпозицию;
- когда что-то застревает на доске.
В этих случаях мы собирались вместе и ходили по плате справа налево, спрашивая инженеров, что случилось и кто может помочь.
Важно, что мы исходили из задач, а не пытались подсчитать, что делают люди;
- когда были запланированы задачи на спринт (каденция пополнения);
- когда функции были приняты;
- встречи между командами разработчиков, например, при обсуждении формата API или решении, какие события передавать.
Инженеры радикально изменили свое отношение к встречам; раньше они им не нравились, а теперь наоборот, они кажутся им нужными и полезными.
Мотивация и вовлеченность команды
Все, что мы ввели: WIP-лимиты, оценку задач на основе статистики, исключение бесполезных задач и т. д., описанное выше, привело к тому, что у инженеров высвободилось время.Что они будут делать теперь? Самое большое заблуждение состоит в том, что никто ничего не сделает. Я сам неоднократно слышал от ребят: «Я бы этот код рефакторил, а то черт ногу сломает».
Да, поначалу инженер действительно выспится и отдохнет недели 2-3, а что дальше? Сидит без задач, начинает обращаться к коллегам с предложением помощи, помогает им выполнить задания, потом оба сидят без задач.
«Пошли исправлять ошибки» — графа с ошибками пуста.
«Поехали рефакторить код» — код можно писать быстрее, WIP-лимит можно увеличить.
Потом начинают внедрять CD/CI и писать базу знаний.
Что случилось? Инженеры начинают делать много полезных вещей, которые им никогда не доводилось делать.
Это та скорость, которую хочет бизнес, но почему-то ни от кого не может получить.
Раньше инженер злился и хотел, чтобы все оставили его в покое, а теперь парадигма человека изменилась: «Чем теперь я могу вам помочьЭ» Число инициатив росло, и все они исходили снизу, а не сверху.
И в итоге они оказались гораздо полезнее.
Коротко о результатах
- Мы смогли найти узкое место в системе и понять, что не можем сделать больше, чем можем.
- Мы перестали забрасывать разработчиков бесполезной работой и освободили время для более полезных задач.
- Когда инженерам стало нечего делать, они стали лучше оценивать задачи, отлаживать ошибки, начали автоматизировать процессы, появилась база знаний.
- Инженеры перестали испытывать стресс и стали добрее.
- Нам удалось ускорить выпуск новых функций в 4 раза за счет доработок и оптимизации (лимиты WIP увеличились за счет автоматизации и доработок).
- Мы получили статистику для бизнеса и четкое понимание, что и как мы делаем с развитием.
- Мы научились экономить время (отказываясь от ненужных задач, стали продумывать задачи заранее, чтобы избежать дополнительных факторов и т. д.).
- Встречи и встречи проводились тогда, когда они действительно были нужны (стало более гибким).
- Все стали больше думать, количество инициатив увеличилось.
Инициативы, рожденные в команде, всегда лучше того, что исходит сверху.
Процесс шел постоянно, и все были вовлечены в него.
выводы
В этой статье и докладе я хотел привлечь внимание не только к инструментам и подходам, которые я использовал, а, скорее, к самому важному аспекту, который часто остается незамеченным, но, на мой взгляд, не менее важен.Мы начали всю эту перестройку, потому что у нас была боль и мы хотели от нее избавиться.
Вы можете реализовать что-то «в лоб», почитав умные книги или послушав доклад о гибких методологиях, так что, возможно, разработка даже ускорится или продукты будут работать лучше.
Но мы часто забываем, что эти продукты делают люди, и чем лучше мы делаем их жизнь, тем лучше они будут делать продукты.
Например, подхожу к ребятам и спрашиваю: «Что у вас болит? В чем дело?" прежде чем приступить к реализации чего-либо.
И только благодаря такому подходу я смог сделать то, что хочет бизнес – скорость и качество в разработке.
P.S. Мне рассказывали об одной компании в Европе, где приходя в офис, может показаться, что царит полная анархия: разработчики, как сыр в масле, играют в консоли, никто не работает. Но это только на первый взгляд, там такая атмосфера, специально созданная для людей, чтобы они могли творить и совершенствоваться.
Один сотрудник в перерывах между задачами ради развлечения написал на коленке решение, которое в дальнейшем было реализовано, и оно стало приносить компании прибыль.
Надеюсь, что наше российское руководство в ближайшем будущем будет двигаться в этом направлении.
А если у вас по каким-то причинам не получается, задумайтесь над тем, что вы делаете.
Ну или киньте эту статью своему начальнику, может поможет :) Теги: #Разработка стартапов #Управление разработкой #Управление проектами #Управление персоналом #teamleadconf #kanban #организация рабочего процесса
-
Установка Esxi 5.1 На Nuc (Dc3217By)
19 Oct, 24 -
Ричард Хэмминг: Глава 1. Ориентация
19 Oct, 24 -
Icloud – Первое Знакомство
19 Oct, 24 -
Яндекс.афиша. Xss
19 Oct, 24 -
Необычная Модель Управления Проектами
19 Oct, 24
