Как перейти на новый фреймворк и не убить качество продукта

Статья написана в соавторстве с Мэри Ротарь, Co-Founder IAMPM.

В статье рассмотрим опыт изменения SDLC и подхода к работе с качеством в проекте на ScrumBut. Охватить все аспекты не получится, поэтому остановлюсь на самых интересных и наиболее болезненных сторонах проекта.

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

Как все начиналось

В те годы, когда в Киеве зимой еще был снег, а Андрей Шевченко играл в «Динамо», я работал РМ’ом в небольшой проектной команде из семи человек, которая разрабатывала ПО для крупного заказчика.

Новый проект был связан с обработкой документов в одном из госучреждений:

• система преобразовывала входящие документы с помощью встроенного механизма, который мы приобрели у третьей компании;
• эти документы выкладывались на онлайн-портале с разными уровнями доступа: некоторые были полностью открыты, другие — только для авторизированных пользователей;
• портал посещали около 300 тыс. уникальных пользователей в месяц, что для этого ресурса было достаточно неплохо.

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

С чем столкнулись

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

Проблема 1. За все отвечает подрядчик. То есть мы

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

В госсекторе работа изначально поставлена по принципу, что заказчик прав без вариантов. Или так — подрядчик всегда не прав :) Мы как подрядчики должны подчиняться решению заказчика, но в случае проблем виновными, естественно, сделают нас.

Нам было сложно фокусироваться на реальной поставке, на том, что приносит ценность клиенту, потому что постоянно возникал вопрос: «На кого возложить ответственность?». С заказчиком обсуждали в основном не требуемую функциональность, а то, как наказать невиновных и наградить непричастных. Эти обсуждения иногда длились 3-4 часа.

Проблема 2. Нет планирования, зато есть дедлайны

Заказчик не мог четко сформулировать, как развивать продукт, потому что многие моменты требовали согласования с вышестоящими инстанциями. Он подчинялся министерству, а поскольку это госсектор, такие согласования растягивались пусть не на месяцы, но на недели точно. Ладно, что я приукрашиваю: однажды мы ждали 7 недель ответ на запрос по одному из компонентов системы.

Пока ждали ответа свыше, надо было работать. И мы делали так, как считали нужным, не всегда попадая в видение министерства. Бережливое производство? Устранение потерь? А не, не слышали.

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

Плохо было и то, что мы работали в постоянных дедлайнах: сроки были «просто вчера», «совсем вчера» и крайний вариант, когда у нас даже «завтра было вчера».

Негативные моменты ситуации:

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

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

Процесс практически отсутствовал, обратная связь действовала в режиме: «Это не так, вы сделали неправильно». По большому счету каждый релиз проходил в ожидании проклятий, которые мы получим от заказчика после первичного тестирования. Успех релиза измерялся пропорционально количеству «WTF?»: чем меньше, тем лучше.

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

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

Как подготовить команду к изменениям

В то время я познакомился со Scrum-фреймворком, прочитав одну из самых известных на тот момент книг о нем — Scrum and XP from the trenches by Henrik Kniberg. Книга обескураживала простотой. Вот уж действительно «серебряная пуля»: как Хенрик добился успешного успеха в короткие сроки с простым инструментом.

Основная мысль: есть некий рамочный фреймворк, который позволит менеджеру с командой взять процессы под контроль и вовлечь заказчика (а это для меня было на тот момент самым главным!) в совместную работу. Бинго!

Итак, вооружившись познаниями из книги и еще из пары источников, я пошел к своей команде и сказал: «Ребятки, с понедельника мы будем жить по Scrum’у».

И здесь я совершил сразу две ошибки, с которыми сталкиваются многие, когда пытаются улучшить качество процессов в организации/проекте: во-первых, начал революционные, а не эволюционные изменения, «с понедельника», а не с этапа подготовки. Во-вторых, в команде не была создана атмосфера необходимости перемен.

Если резко внедрять крупные новшества на проекте, появляется риск столкнуться со следующими проблемами:

• Сопротивление на уровне людей, которым с этими изменениями жить. Человек привыкает даже к неудобным условиям, выбирает пресловутую зону комфорта и не готов ее менять. По принципу «хуже не будет», если вы поняли, о чем я ;)
• Влияние резких масштабных изменений сразу же приводит к снижению производительности, порождая увеличение стресса и недоверия к агентам изменений и самой идее.

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

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

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

Ключевые аспекты работы с заинтересованными лицами

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

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

В то время софт мы поставляли «кагбэ on demand» (по требованию). Требование обычно выглядело так: «Когда, наконец [несколько непечатных междометий], вы нам что-то поставите?!».

Когда мы просили зафиксировать требования, заказчик возражал: «Мы не можем зафиксировать требования, потому что они постоянно меняются». Я предлагал: «Давайте так: если на своей стороне сможете зафиксировать требования на неделю или две, то мы за это время с высокой долей вероятности поставим то, что хотите».

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

С каждым мы торговались о своем. Департаменту, который занимался настройкой системы, предложили: «Вы больше не будете неожиданно получать от нас сборку и оставаться поздним вечером на работе, пытаясь накатить все эти изменения на продакшн. Теперь будете знать, что каждый второй четверг получите набор нового функционала и сможете его ставить на свои продсервера».

Мы продали команде саппорта продакшн-серверов поставку каждые две недели по четвергам, а за это получили сопровождение в тестировании: они выступали нашим user acceptance testing. Команда саппорта разворачивала наш билд у себя на тестовой среде, тестировала и возвращала ошибки. Большой менеджмент об этих ошибках не знал, потому что мы решали вопрос в своем тесном мирке путем переговоров.

Превратите заказчика в союзника

Одной из проблем, которую мы хотели решить, было отсутствие четких требований к продукту:

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

Из трех отделов мы выбрали один, который непосредственно отвечал за работоспособность продукта. Вместе с заказчиком решили, что ключевой человек для команды — тот, кто контролирует 50 контент-менеджеров в выбранном отделе. И только этот человек может выступать для нас, подрядчиков, в роли product owner’а и постановщика задач.

Теперь к нашему product owner’у стекались пожелания трех отделов, и он получил некую формальную власть над тем, что в продукте будет внедряться. Если поступали задачи из других отделов, мы отправляли «постановщиков» к product owner’у и только в том случае, когда он давал добро, брали задачи в работу.

Что получилось в итоге

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

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

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

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

В подобной ситуации заказчик обычно самоустраняется: «Вы, ребята, технари, сами между собой разберитесь», но с появлением product owner’а ситуация изменилась.

Появился один человек, который принимал решение, что необходимо реализовывать. Product owner аккумулировал в себе конфликты, приоритизировал работу с дефектами, активно фасилитировал нашу совместную работу. Число конфликтов значительно уменьшилось. Могу даже сказать, что мы перешли на партнерско-приятельские отношения, так как области ответственности были четко обозначены и ситуации «с нашей стороны пули вылетели, проблемы на вашей стороне» спустя 3-4 месяца полностью исчезли.

Оптимизация текущих процессов

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

Поработали с требованиями

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

Поэтому мы внедрили процесс по управлению требованиями с явно выделенной ролью аналитика — человека, который фиксировал запросы от product owner’а, вносил их в Jira и Confluence. Одной из целей была четкая фиксация всех запросов заказчика и, главное, учета изменений.

Разграничили ответственность

С кросс-функциональностью у нас не получилось, если понимать под этим, что любой участник команды способен делать работу за другого. Например, если аналитик простаивает, то почему бы ему не протестировать вместе с тестировщиком.

Учитывая достаточно сложную структуру продукта, попытки привлечь к ряду операций непрофильных людей были чреваты проблемами для нас и заказчика. Мы выделили конкретных специалистов, которые отвечали за определенный этап: программировали, тестировали, писали требования, настраивали серверную часть — и не выполняли другие обязанности. Если у сотрудника не было задач, он «простаивал», но не делал лишнюю работу «впрок». Рефакторинг, наведение порядка с документацией, формализация процессов — всегда было чем заняться.

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

Так как у нас не было доступа к этим серверам, мы четко описали требования к системному ПО, элементы конфигурационного управления, правила работы с релизами. Этот документ был доступен в любое время и нам, и заказчику.

Внедрили Built-in Quality

Термин Built-in Quality (встроенное качество) означает, что контроль качества продукта происходит не в самом конце, а планируется для всех этапов разработки. Цель такого контроля — чтобы каждый элемент решения в каждом инкременте соответствовал принятым стандартам.

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

Например, часто возникает ситуация, когда нужно что-то срочно поставить на продакшн и заказчик предлагает: «Давайте пропустим тестирование и сделаем быстрее, а позже что-нибудь придумаем».

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

Другой важный аспект работы с качеством — это выработка ясных зон ответственности — кто за что отвечает. Для определения ролей каждого участника команды в модели коммуникаций используют RACI-матрицу:

1. Responsible — ответственный за какую-то задачу.
2. Accountable — утверждающий, проверяющий, ответственный за общий результат.
3. Consulted — тот, с кем консультируются для выполнения.
4. Informed/interested — человек, которого информируют о том, что задача выполнена.

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

Если «непокрытые» этапы не выявить и не назначить руководителя, это может серьезно снизить качество проекта.

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

Вместо вывода

1. Перед тем как внедрять что-то новое, нужно сформировать у людей потребность в изменениях. Если эффективность работы всех устраивает и нет чувства проблемности ситуации, то перейти на другие модели процессов будет нелегко. На эту тему есть хорошая книжка Джона Коттера «Наш айсберг тает». Там в шуточной форме на примерах пингвинов описаны базовые принципы внедрения изменений.
2. Следующий шаг — принять необходимость изменений. Когда люди осознали, что изменения нужны, начинайте подготовку. Здесь я рекомендую почитать о канбан-методе, например, книгу Kanban from the Inside Майка Барроуза.
3. Проанализируйте текущую ситуацию: проблемы и причины их появления, от кого поступают требования, как распределяются обязанности в команде.
4. Решите, что можно оптимизировать: текущие процессы, взаимодействие с заказчиком, ответственность.
5. Внедряйте изменения небольшими порциями, отслеживайте, как они отражаются на проекте, и двигайтесь дальше к новым стандартам качества.