татья написана в соавторстве с Мэри Ротарь, Co-Founder IAMPM.
В статье рассмотрим опыт изменения SDLC и подхода к работе с качеством в проекте на ScrumBut. Охватить все аспекты не получится, поэтому остановлюсь на самых интересных и наиболее болезненных сторонах проекта.
Думаю, история будет полезна менеджерам и всем, кто отвечает за конечный результат перед заказчиком.
Новый проект был связан с обработкой документов в одном из госучреждений:
В госсекторе работа изначально поставлена по принципу, что заказчик прав без вариантов. Или так — подрядчик всегда не прав
Мы как подрядчики должны подчиняться решению заказчика, но в случае проблем виновными, естественно, сделают нас.
Нам было сложно фокусироваться на реальной поставке, на том, что приносит ценность клиенту, потому что постоянно возникал вопрос: «На кого возложить ответственность?». С заказчиком обсуждали в основном не требуемую функциональность, а то, как наказать невиновных и наградить непричастных. Эти обсуждения иногда длились 3-4 часа.
Пока ждали ответа свыше, надо было работать. И мы делали так, как считали нужным, не всегда попадая в видение министерства. Бережливое производство? Устранение потерь? А не, не слышали.
Позже приходилось переделывать какие-то задачи, и это влияло на качество не лучшим образом. Тем более, что не было ясности, нужно ли будет снова дорабатывать задачу или это все-таки финальная версия, которую можно фиксировать и отдавать на прод.
Плохо было и то, что мы работали в постоянных дедлайнах: сроки были «просто вчера», «совсем вчера» и крайний вариант, когда у нас даже «завтра было вчера».
Негативные моменты ситуации:
Процесс практически отсутствовал, обратная связь действовала в режиме: «Это не так, вы сделали неправильно». По большому счету каждый релиз проходил в ожидании проклятий, которые мы получим от заказчика после первичного тестирования. Успех релиза измерялся пропорционально количеству «WTF?»: чем меньше, тем лучше.
В таких условиях проект функционировал несколько месяцев до меня и еще какое-то время вместе со мной, пока мы разбирались с происходящим. Команда успешно-неуспешно пилила нужный софт, постоянно «выгребая» от клиента. При этом мы пытались следить за качеством функционала и старались улучшить результат работы, пусть даже с помощью плохой обратной связи.
На этом этапе было сложно говорить о вопросах качества. Было необходимо как-то устаканить процесс разработки, внедрить предсказуемые и повторяемые активности, которые будут полезны и команде, и нашему клиенту, чтобы он все-таки мог получать что-то предсказуемое в обозримые сроки.
Основная мысль: есть некий рамочный фреймворк, который позволит менеджеру с командой взять процессы под контроль и вовлечь заказчика (а это для меня было на тот момент самым главным!) в совместную работу. Бинго!
Итак, вооружившись познаниями из книги и еще из пары источников, я пошел к своей команде и сказал: «Ребятки, с понедельника мы будем жить по Scrum’у».
И здесь я совершил сразу две ошибки, с которыми сталкиваются многие, когда пытаются улучшить качество процессов в организации/проекте: во-первых, начал революционные, а не эволюционные изменения, «с понедельника», а не с этапа подготовки. Во-вторых, в команде не была создана атмосфера необходимости перемен.
Если резко внедрять крупные новшества на проекте, появляется риск столкнуться со следующими проблемами:
Скажу сразу, мне понадобилось три попытки, чтобы самому разобраться во фреймворке и убедить команду, что переход на Scrum улучшит качество процессов и продукта в нашем конкретном случае. Это важный момент, так как Scrum «надевается» далеко не на все проекты.
После объяснений, совместных рассуждений и нескольких экспериментов, например, внедрения физической доски, команда приняла новый подход.
Поскольку на стороне клиента были игроки разного уровня, мы с командой выработали некие тактические подходы: кому и что можно продать из Scrum’а.
В то время софт мы поставляли «кагбэ on demand» (по требованию). Требование обычно выглядело так: «Когда, наконец [несколько непечатных междометий], вы нам что-то поставите?!».
Когда мы просили зафиксировать требования, заказчик возражал: «Мы не можем зафиксировать требования, потому что они постоянно меняются». Я предлагал: «Давайте так: если на своей стороне сможете зафиксировать требования на неделю или две, то мы за это время с высокой долей вероятности поставим то, что хотите».
Для заказчика это было хорошим аргументом, потому что он тоже отчитывался перед своим руководством и так было легче обещать что-то министерству в конкретные сроки.
С каждым мы торговались о своем. Департаменту, который занимался настройкой системы, предложили: «Вы больше не будете неожиданно получать от нас сборку и оставаться поздним вечером на работе, пытаясь накатить все эти изменения на продакшн. Теперь будете знать, что каждый второй четверг получите набор нового функционала и сможете его ставить на свои продсервера».
Мы продали команде саппорта продакшн-серверов поставку каждые две недели по четвергам, а за это получили сопровождение в тестировании: они выступали нашим user acceptance testing. Команда саппорта разворачивала наш билд у себя на тестовой среде, тестировала и возвращала ошибки. Большой менеджмент об этих ошибках не знал, потому что мы решали вопрос в своем тесном мирке путем переговоров.
Теперь к нашему product owner’у стекались пожелания трех отделов, и он получил некую формальную власть над тем, что в продукте будет внедряться. Если поступали задачи из других отделов, мы отправляли «постановщиков» к product owner’у и только в том случае, когда он давал добро, брали задачи в работу.
Как результат, за три месяца количество платных пользователей портала увеличилось на 50%. Построив качественный процесс сбора требований и получения обратной связи, мы помогли заказчику не только выполнять его обязанности, но и зарабатывать самой организации и конкретным сотрудникам, потому что специалисты получали премии.
Соответственно, у нас появилось много благодарных коллег на стороне клиента, потому что заказчик понял: если формулировать свои ожидания и потребности более четко, мы будем их быстрее и лучше реализовывать.
Мы также получили хорошее подспорье в тестировании. Когда product owner увидел, что может влиять на продукт, то подключил свою команду тестировать вместе с нами. Продукт был непростым, имел сложную архитектуру и использовал ПО стороннего разработчика. Нужно было состыковать спецификации, как будут обмениваться данными компоненты, отслеживать, на чьей стороне возможны дефекты. Естественно, не обходилось без конфликтов.
В подобной ситуации заказчик обычно самоустраняется: «Вы, ребята, технари, сами между собой разберитесь», но с появлением product owner’а ситуация изменилась.
Появился один человек, который принимал решение, что необходимо реализовывать. Product owner аккумулировал в себе конфликты, приоритизировал работу с дефектами, активно фасилитировал нашу совместную работу. Число конфликтов значительно уменьшилось. Могу даже сказать, что мы перешли на партнерско-приятельские отношения, так как области ответственности были четко обозначены и ситуации «с нашей стороны пули вылетели, проблемы на вашей стороне» спустя 3-4 месяца полностью исчезли.
Поэтому мы внедрили процесс по управлению требованиями с явно выделенной ролью аналитика — человека, который фиксировал запросы от product owner’а, вносил их в Jira и Confluence. Одной из целей была четкая фиксация всех запросов заказчика и, главное, учета изменений.
Учитывая достаточно сложную структуру продукта, попытки привлечь к ряду операций непрофильных людей были чреваты проблемами для нас и заказчика. Мы выделили конкретных специалистов, которые отвечали за определенный этап: программировали, тестировали, писали требования, настраивали серверную часть — и не выполняли другие обязанности. Если у сотрудника не было задач, он «простаивал», но не делал лишнюю работу «впрок». Рефакторинг, наведение порядка с документацией, формализация процессов — всегда было чем заняться.
Такой подход позволил прописать процессы разработки, тестирования, а затем согласовать с заказчиком, по каким правилам пишем код и по каким сценариям тестируем. И это серьезно упростило работу с командой заказчика, которая размещала наш софт на продакшн-серверах.
Так как у нас не было доступа к этим серверам, мы четко описали требования к системному ПО, элементы конфигурационного управления, правила работы с релизами. Этот документ был доступен в любое время и нам, и заказчику.
Встроенное качество — это основа, которую необходимо внедрять в ДНК процесса. Мы договорились с заказчиком, что не будем пропускать ни один из шагов, важных для поставки качественного продукта.
Например, часто возникает ситуация, когда нужно что-то срочно поставить на продакшн и заказчик предлагает: «Давайте пропустим тестирование и сделаем быстрее, а позже что-нибудь придумаем».
Мы не соглашались идти без тестирования, даже при внешнем давлении по срокам. Иначе потом могли возникнуть серьезные проблемы уже с конечными пользователями.
Другой важный аспект работы с качеством — это выработка ясных зон ответственности — кто за что отвечает. Для определения ролей каждого участника команды в модели коммуникаций используют RACI-матрицу:
Если «непокрытые» этапы не выявить и не назначить руководителя, это может серьезно снизить качество проекта.
Перестройка процессов заняла у нас около полугода: пара месяцев ушла на борьбу с инертностью мышления команды и заказчика, остальное время — на работу с процессами.
dou.ua
В статье рассмотрим опыт изменения SDLC и подхода к работе с качеством в проекте на ScrumBut. Охватить все аспекты не получится, поэтому остановлюсь на самых интересных и наиболее болезненных сторонах проекта.
Думаю, история будет полезна менеджерам и всем, кто отвечает за конечный результат перед заказчиком.
Как все начиналось
В те годы, когда в Киеве зимой еще был снег, а Андрей Шевченко играл в «Динамо», я работал РМ’ом в небольшой проектной команде из семи человек, которая разрабатывала ПО для крупного заказчика.Новый проект был связан с обработкой документов в одном из госучреждений:
- система преобразовывала входящие документы с помощью встроенного механизма, который мы приобрели у третьей компании;
- эти документы выкладывались на онлайн-портале с разными уровнями доступа: некоторые были полностью открыты, другие — только для авторизированных пользователей;
- портал посещали около 300 тыс. уникальных пользователей в месяц, что для этого ресурса было достаточно неплохо.
С чем столкнулись
В то время, когда я пришел в проект, там был постоянный хаос и проблемы: мы не попадали в собственные оценки, команда не укладывалась в сроки, приоритеты распределялись по известному принципу 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. Команда саппорта разворачивала наш билд у себя на тестовой среде, тестировала и возвращала ошибки. Большой менеджмент об этих ошибках не знал, потому что мы решали вопрос в своем тесном мирке путем переговоров.
Превратите заказчика в союзника
Одной из проблем, которую мы хотели решить, было отсутствие четких требований к продукту:- Представитель заказчика поставлял нам требования о работе системы в форме неких мыслей. Эти идеи о продукте рождались у него обычно либо накануне встречи, либо в ходе нашего обсуждения.
- Спецификации и документация отсутствовали.
- Три отдела заказчика, о которых я говорил в начале, вбрасывали нам идеи и задачи без всякой приоритизации.
Теперь к нашему 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-матрицу:
- Responsible — ответственный за какую-то задачу.
- Accountable — утверждающий, проверяющий, ответственный за общий результат.
- Consulted — тот, с кем консультируются для выполнения.
- Informed/interested — человек, которого информируют о том, что задача выполнена.
Если «непокрытые» этапы не выявить и не назначить руководителя, это может серьезно снизить качество проекта.
Перестройка процессов заняла у нас около полугода: пара месяцев ушла на борьбу с инертностью мышления команды и заказчика, остальное время — на работу с процессами.
Вместо вывода
- Перед тем как внедрять что-то новое, нужно сформировать у людей потребность в изменениях. Если эффективность работы всех устраивает и нет чувства проблемности ситуации, то перейти на другие модели процессов будет нелегко. На эту тему есть хорошая книжка Джона Коттера «Наш айсберг тает». Там в шуточной форме на примерах пингвинов описаны базовые принципы внедрения изменений.
- Следующий шаг — принять необходимость изменений. Когда люди осознали, что изменения нужны, начинайте подготовку. Здесь я рекомендую почитать о канбан-методе, например, книгу Kanban from the Inside Майка Барроуза.
- Проанализируйте текущую ситуацию: проблемы и причины их появления, от кого поступают требования, как распределяются обязанности в команде.
- Решите, что можно оптимизировать: текущие процессы, взаимодействие с заказчиком, ответственность.
- Внедряйте изменения небольшими порциями, отслеживайте, как они отражаются на проекте, и двигайтесь дальше к новым стандартам качества.
DOU
DOU – Найбільша спільнота розробників України. Все про IT: цікаві статті, інтервʼю, розслідування, дослідження ринку, свіжі новини та події. Спілкування на форумі з айтівцями на найгарячіші теми та технічні матеріали від експертів. Вакансії, рейтинг IT-компаній, відгуки співробітників, аналітика...
dou.ua