Под катом рассказ в формате “от первого лица” от моего коллеги по Altenar IT-аналитика Андрея Андрианова. Надеюсь, что наш опыт об особенностях рефакторинга будет вам полезен.
Вы когда-нибудь делали ремонт квартиры? Красивый проект, четкий план, эйфория от предвкушения скорого результата, живой огонь в глазах работников, их оптимистичные обещания на старте… Но все это довольно быстро сменяется разочарованием, горечью и непреходящим желанием быстрее закончить до боли любимый ремонт с минимальными издержками моральных сил и материальных ресурсов. Ведь довольно скоро появляются первые трудности и задержки. Материалов внезапно оказывается недостаточно, а имеющиеся были банально подобраны неправильно.
Неожиданно возникают новые неучтенные работы, а сложность запланированных оказывается катастрофические недооцененной, работники дают невнятные объяснения причин возникших трудностей и рисуют туманные перспективы по их устранению. При этом качество работ настолько “выдающееся”, что многое приходится переделывать, причем зачастую с привлечением других работников. Смета растет, сроки улетают за видимый горизонт, но обратного пути уже нет. Добро пожаловать в мир рефакторинга!
Суть и объект рефакторинга
Причем тут рефакторинг, да еще и в сфере ИТ, спросите вы. А при том, что именно с выше озвученным сценарием мы столкнулись в нашей идеалистической попытке отрефачить один из важнейших инструментов главного продукта компании.
Данная статья о наших трудностях, путях их преодоления и о том профите для компании, ради которого стоило пройти через боль мучительных трудностей и преодолений длиною в 5 месяцев. И если тема рефакторинга для вас не является достаточно актуальной, то данная статья вполне может предостеречь вас от ошибок в ремонте вашей квартиры.
Сразу оговорюсь, что хоть статья и была в основном навеяна опытом реализации данного проекта рефакторинга, тем не менее она обобщает ежедневную работу нашей компании, с которой я прямо или косвенно соприкасаюсь. И так удивительным образом получается, что разнообразного рефакторинга в этой работе наблюдается все больше и больше.
Сам рефакторинг и реализация новых фич иногда настолько переплетены и неразделимы между собой, что порой сложно отличить одно от другого. По этой причине данную статью можно отнести ко многому из того, что происходит в нашей компании. Естественно все это с поправкой восприятие происходящего через призму моих персональных и потенциально не всегда объективных взглядов.
Прежде всего устраним всякую неоднозначность и ясно раскроем смысл, заложенный в понятие “рефакторинг” в контексте данной статьи. Здесь не идет речь об узкоспециальных видах рефакторинга технического плана, как то рефакторинг кода, баз данных, архитектуры. Точнее, все это предполагается как возможные, но необязательные технические задачи в рамках гораздо более широкого по содержанию проектов рефакторинга.
Определим здесь рефакторинг как функциональное и техническое обновление определенной части продукта, причем обновление настолько масштабное, что оно приводит к созданию новой значительной бизнес-ценности.
Итак, наша компания, выражаясь международным языком, является sportsbook software provider. В этой нише у нас есть свой флагманский продукт, на развитии которого сосредоточены наши постоянные усилия.
В бэк-офисе нашего продукта есть инструмент управления результатами событий. Этот инструмент один из наиболее часто используемых и важных с точки зрения обеспечения бесперебойной операционной деятельности компании. Его работа связана с визуализацией большого объема данных и управлением отдельными элементами этих данных, включая их фильтрацию, ручное изменение и сохранение.
Инструмент состоит из двух форм: управление событиями и управление результатами событий. Объем данных на второй форме может достигать более тысячи объектов, внутри которых еще не менее двух элементов управления с семью вариантами выбора. И все это на одной странице, и без пагинации.
Для понимания контекста сделаем небольшой экскурс в бэкграунд нашего продукта. На момент запуска проекта рефакторинга бэкофис был полностью написан бэкэнд командой на C# с использованием фреймворка Kendo UI и поддерживался ее силами. Это создавало две крупные проблемы:
бекэнд постоянно отвлекался на админку в ущерб задачам по серверной логике,
само качество админки перестало соответствовать нашим требованиям с функциональной и UI/UX точек зрения.
Мы прекрасно понимали, что в том виде бэк-офис был реализован как временное решение и стал жертвой стремления в максимально короткие сроки выкатить на продакшн новую версию нашего флагманского продукта. Наступил момент, когда важность новых бизнес-требований к бэк-офису перевесила его существующий технический потенциал, и в компании было принято стратегическое решение полностью переписать админку. Ведь помимо более эффективного использования ее на своей стороне мы планировали существенно расширить ее использование нашими клиентами.
Среди поставленных на тот момент целей: реализация нового функционала с возможностью его гибкого и оперативного наращивания, кардинальный пересмотр разработка нового интерфейса UI/UX специалистами, использование новых технологий имплементации фронтенда.
Двигаться к этим целям было решено, постепенно обновляя форму за формой, т.е. встраивать отрефакторенные страницы вместо старых в существующий бэк-офис. В конечном итоге по нашему плану данный процесс должен был привести к полному поглощению обновленной админкой ее предшественницы.
Реализацию фронтенда было решено вести фронтенд-командой на Java Script с использованием фреймворка React и библиотеки Material-UI. Забегая вперед, нужно сказать, что выбор “реакта” стал роковой ошибкой этого проекта, поскольку на тот момент в компании для всех продакшн-решений использовался фреймворк Vue. Сейчас постфактум можно сказать, что с началом масштабной разработке на “реакте” мы поторопились, но мы все ведь прекрасно понимаем, что жизнь без амбициозных челленджей скучна и неинтересна.
Применительно к проекту рефакторинга вышеописанного инструмента можно зафиксировать два крайних состояния:
исходное: у нас есть “не совсем хороший инструмент”;
желаемое: мы хотим иметь “очень хороший инструмент”.
Вектор между этими состояниями задает траекторию реализации проекта, а “разность потенциалов” между ними - мотивацию, энергию и скорость движения по этой траектории. С мотивацией и энергией у нас все было в порядке, а вот на пункте “скорость” наши планы дали критический сбой. Но об этом по порядку.
Далее я сделаю акцент на команде проекта, как на его важнейшем ресурсе, фактически сложившихся этапах жизненного цикла проекта, и, самое главное, на уроках, которые мы с пользой извлекли из этого челленджа, коим по факту и стал для нас этот проект. Но прежде всего я должен перечислить основные результаты, которые мы получили в сухом остатке на выходе проекта для понимания контекста дальнейшего повествования:
Запредельные сроки реализации. Вместо ожидаемых 1-1.5 месяцев мы получили 5. Не имея опыта в планировании и реализации столько крупных проектов рефакторинга, мы могли себе позволить некоторую вольность в планировании сроков, но мы не ожидали, что все зайдет так далеко.
Работающий функционал. Он удовлетворяет 99% бизнес-требований. Существует ряд минорных недочетов, устранение которых отложено в связи со следующим пунктом.
Низкий уровень технической реализации отдельных аспектов фронтенд-части, в частности, архитектуры и отдельных компонентов. Это не позволяет нам сейчас гибко и оперативно модернизировать инструмент и требует нового мини-рефакторинга.
Команда смельчаков
Состав команды проекта определялся его содержанием:
необходимо было реализовать достаточно крупный объем новой базовой серверной логики, обеспечивающей расширенную обработку входящих данных согласно новым бизнес-требованиям;
требовалось реализовать бекенд (API) и фронтенд (интерфейс) часть нового инструмента, работающего с новой серверной логикой;
разумеется, нужно было разработать мокап нового инструмента, воплотив в интерфейсе лучшие UI/UX идеи, на которые была способна наша компания на тот момент;
комплексное тестирование нового крупного инструмента требовало нетривиальных усилий со стороны QA команды.
Казалось бы, можно сформировать SCRUM-самоорганизующуюся проектную команду из необходимых технических специалистов, поставить команде задачу и через разумный срок просто получить готовый результат. Мы так наивно и полагали. Могу предположить, что многие читающие эту статью понимают, что такой технократический идеализм на практике, как правило, не работает.
Наибольший сбой вызывают интерпретация бизнес-требований в те конкретные задачи, которые попадают на вход к разработчикам в нужном объеме, с понятной трактовкой и в правильной последовательности, а также обеспечение скоординированной работы всех участников команды, оперативное преодоление всех текущих проблем и поступательное создание продукта. Вся причина в том, что крупная задача, помноженная на немалое число разноплановых специалистов, вовлеченных в ее решение, часто становится нерешаемой без применения нестандартных организационных подходов, релевантных каждой конкретной компании.
Пытаясь исповедовать нестандартное мышление, еще перед стартом мы твердо решили, что в проекте помимо технических специалистов нам необходимо связующее звено, которое объединит всех участников команды и будет перманентно направлять их усилия в общее русло в точном соответствии с бизнес-требованиями, а заодно обеспечит создание и эффективную работу всех необходимых процессов по реализации проекта, начиная от первичного взаимодействия со стейкхолдерами и заканчивая удовлетворением их потребностей результатами финального релиза.
У нас в компании нет какого-то строгого формализованного “проджект менеджемента”. В принципе его у нас вообще нет. У нас есть отличные технические специалисты, двухнедельные спринты и много-много митингов. Во всяком случае, так было на момент старта проекта.
И в этом вопросе мы сделали ход конем. По инициативе бизнес-аналитика, между прочим автора данной статьи, мы решили наделить его функциями руководителя проекта (кто бы сомневался). Он как никто другой знает бизнес-требования, владеет коммуникациями со стейкхолдерами и к тому же пишет задачи для разработчиков, т.е. фактически сопровождает весь жизненный цикл новых фич продукта.
Данное решение также выглядело очень привлекательным с точки зрения оптимизации организационных затрат, позволяя загрузить существующую штатную единицу важным управленческим функционалом вместо создания новой роли и найма дополнительного сотрудника. Забегая вперед, отмечу, что такой подход не только себя полностью оправдал, но и стал основой существующего ныне управления проектами в компании.
В рамках того проекта рефакторинга вместо понятия “руководитель проекта” я предпочитал использовать обозначение “координатор”, стараясь сохранить горизонтальный формат команды и не выделять эту роль в качестве управленческой. В моем понимании, данный координатор - это один из рядовых членов команды, который, как и все остальные, решает технические вопросы по проекту (в данном случае, работает над бизнес-требованиями, формулирует задачи, описывает алгоритмы, логику).
Тем не менее для простоты понимания будем стандартно называть его руководителем проекта (РП). Итак, мы ввели в проект управленческую единицу в лице бизнес-аналитика с функциями РП. В дальнейшем, упоминая РП, мы будем подразумевать, что он в том числе является бизнес-аналитиком.
От себя добавлю, что перед собой, как перед РП, я дополнительно поставил сверхзадачу максимально раскрыть потенциал команды проекта и каждого участника в отдельности дабы повысить продуктивность совместной работы насколько это было возможно и решить для себя личные задачи развития как управленца.
На мой взгляд в этом направлении очень часто присутствуют нераскрытые командные резервы и точки роста. Ставку я делал на обеспечение предельной ясности задач для разработчиков, скоординированность действий, персональную работу с каждым участником проекта для полного и результативного вовлечения в общий процесс и, наконец, прозрачность для команды планов по проекту с четкой ориентацией на финальный результат, чтобы фокус на конечном желаемом состоянии постоянно сохранялся.
Если видеть гору, на которую надо взобраться, то лес, стоящий перед ней, не станет трудно преодолимой преградой. Но если видеть только тот же лес, то пройти через него станет тяжелее, не имея перед глазами более крупной конечной цели.
Аспект работ | Команда на момент старта | Производственный результат и организационные последствия |
UI/UX | В компании уже несколько месяцев работал UI/UX специалист высокого уровня, для которого участие в данном проекте стало первой и к тому же очень крупной и непростой задачей в отношении нашего основного продукта. | Задача была решена быстро и качественно. Это стало следствием очень плотной работы РП с дизайнером. Со стороны РП был представлен предварительный драфт мокапа. Дизайнер его полностью творчески переработал, получив предельно полное понимание бизнес-контекста от РП. В начале реализации ряд улучшений мокапа дополнительно был произведен по инициативе разработчиков, что стало важным достижением нашей команды, как продуктивной самоорганизующейся команды. Мокап был согласован со стейкхолдерами. Данная работа затруднений не вызвала благодаря сильным компетенциям дизайнера и заложила фундамент дизайнерских решений нашего бэкофиса на базе библиотеки Material-UI. В настоящее время наше UI/UX подразделение выросло до четырех человек. Работа по созданию высококачественных интерфейсов поставлена на поток. |
Базовая серверная логика | В компании работала единая бэкенд-команда, которая занималась всей серверной логикой, а также полностью поддерживала бэк-офис. Разделение внутри команды на отдельные компоненты и блоки системы было условным. На проект был выделен разработчик, имевший опыт, релевантный содержанию проекта. | Реализация также строилась на плотной работе РП с разработчиком для обеспечения предельной ясности логики для последнего. Сама логика была объемной и непростой, состояла из нескольких крупных эпиков, затрагивала логическое ядро нашего продукта, что вызывало трудности в понимании некоторых моментов требований в процессе реализации. Разработчик также вносил предложения по оптимизации бизнес-требований, согласовывая их с особенностями подкапотной работы продукта. В целом, данная задача была выполнена также быстро и качественно. В последствии, уже в ходе реализации проекта, вся бэкенд команда была разделена на несколько прикладных команд в соответствии с системными компонентами и предметной областью работы нашего продукта. Это позволило максимально прокачать разработчиков в определенных прикладных направлениях и тем самым повысить качество реализации. |
Бэкенд часть бэк-офиса | Данное направление работ было практически новым для нас. Монолитную архитектуру продукта необходимо было разделить на серверную логику и логику бэк-офиса. Со стороны бэкенда требовалось разработать API для фронтенда по проекту и в целом архитектуру, технический подход к разработке и поддержке API для дальнейшего развития бэкофиса на новых рельсах. Специалистов, обладающих большим опытом именно в этом вопросе, кроме лида команды бэкенда, у нас не было. Добровольцем вызвался один из бекенд разработчиков, посчитавший для себя интересным принять участие в новом для компании проекте с перспективой дальнейшего развития бэкофиса. Помимо мотивации он обладал очень большим профессиональным потенциалом, и был включен в команду проекта. | Ответственные и профессиональные люди зачастую бывают перфекционистами. Так, и в данном случае наш специалист вместо скорейшей разработки API в полном объеме и передачи ее команде фронтенда стал заниматься поиском некоего лучшего подхода для разработки и поддержки API. Короче, он занялся исследовательской работой на перспективу, о которой его напрямую никто не просил. Это произошло не от того, что он не хотел/не мог заниматься текущими задачами по проекту, а от некорректной обратной связи со стороны команды фронтенда в начале разработки. Он просто действовал согласно договоренностям с фронтендщиками о том, что делает методы API последовательно по их запросу, поэтому не спешил с полной разработкой и параллельно по своей инициативе занимался задачей развития. Безусловно, в этом вопросе он совершил серьезную ошибку, которую мы осознали и скорректировали примерно через месяц после старта проекта. API для новых форм бэкофиса нужно проектировать и разрабатывать сразу в полном объеме, чтобы команда фронтенда получала готовый результат и могла гибко и независимо планировать свою работу. Несмотря на эти временные недоразумения в определенный момент мы резко форсировали разработку API, перешли к командному планированию этой работы и быстро достигли цели. Получив, достаточно большой опыт и мощный импульс профессионального развития от этого проекта, в дальнейшем, данный специалист стал превосходным тим-лидом бэкенд-команды бэкофиса. Его команда растет, а в его лице мы получили высококлассного разработчика, от которого во многом зависит развитие нашего продукта. |
Фронтенд часть бэк-офиса | Это самый интересный и драматический пункт касательно команды проекта. К его старту мы подошли со следующими вводными: 1. У команды фронтенда не было тим-лида (незадолго до этого он покинут компанию). 2. Команда фронтенда не имела опыта разработки на React. 3. В команде фронтенда никто не горел желанием участвовать в этом проекте. Тем не менее на проект был назначен один очень сильный разработчик. Мы все, включая его, думали, что реализация фронтенд-части займет не больше месяца. С таким оптимистичным планом реализации фронтенда мы приступили к делу. | Если говорить кратко, то все пошло не так. А если по пунктам, то: ● Оптимизм в оценках сроков был сильно преувеличен. По факту разработка на React каких-то казалось бы банальных элементов занимала в разы больше времени, чем ожидалось. Мы просто зависали на неделю+ на некоторых задачах, по которым ожидали день-два. И никто с этим не мог ничего поделать, т.к. в компании не было экспертизы в React. ● Изначально не были произведены декомпозиция и планирование разработки всего мокапа. Напомню, что это две функционально сложных формы. Наш разработчик начал реализацию с какого-то одного элемента, не расписав дальнейшие шаги. Как следствие, у нас не было важного раздела в плане проекта, а значит мы не могли управлять ни фронтенд-разработкой, ни всем проектом, и мы не имели возможности распараллелить работу, не проведя декомпозицию и не определив логические связи между подзадачами. ● Работа велась только над одной формой. Как только мы увидели задержку сроков по ней, мы должны были добавить разработчика в проект и дать ему вторую форму для работы в параллели. ● Долгая поэлементная разработка без полной декомпозиции требовала от бэкенда методы API только по текущим элементам. Это усыпило бдительность бекенда, который считал, что все идет по плану, и фронтенд получает все, что ему было нужно. Когда же мы решили добавить в параллель второго разработчика по другой форме, то мы элементарно не смогли этого сделать до тех пор, пока бекенд не доделал свою часть. ● Отсутствие достаточного опыта в React и поэлементная разработка обусловили то, что по второй форме была заложена не оптимальная архитектура, которая до сих пор нам не позволяет совершенствовать функционал на этой форме и вызывает проблемы с производительностью. Требуется архитектурный рефакторинг, о котором я упоминал выше. В целом фронтенд-разработка на этом проекте для нас стала одной большой и очень мучительной проблемой. Всего в проекте поучаствовало 5 разработчиков. По тем или иным причинам бэкофисом продолжает заниматься только один из них. Проект нам не позволил создать фронтенд-команду по бэкофису, но дал нам четкое понимание, что она нам крайне необходима, начиная от тим-лида с отличными компетенциями в React и продолжая грамотными и мотивированными разработчиками. В настоящее время, по прошествии нескольких месяцев после завершения проекта, у нас уже есть крутейший тим-лид и отличная команда под его руководством. Работа полностью унифицирована и структурирована. С командой бэкенда налажено продуктивное взаимодействие. Мы практически счастливы. |
QA | Нам повезло. У нас в компании отличная команда QA. Безусловно, в этом вопросе временами возникают сложные и напряженные моменты, ведь фичи становятся все сложнее и объемнее. На мой взгляд, все подобные передряги мы преодолеваем благодаря тому, что наши тестировщики - очень грамотные и увлеченные люди, которые живут продуктом. В их команде царит особая атмосфера, в которую всегда приятно попадать, потому что, находясь с ней, ты можешь смотреть на продукт свежим критичным взглядом широко открытыми глазами. От QA на проект был назначен специалист, привнесший ту самую атмосферу. К нему в пару на этот проект был прикреплен вновь пришедший в компанию человек. Итого у нас было два тестировщика, один из которых не имел опыта работы в компании. | Пожалуй, это был самый увлекательный аспект работ. Баги сыпались на наши головы неиссякаемым потоком. В какой-то момент времени мы просто начали в них захлебываться и постепенно растворяться. Наши тестировщики норовили выдать на гора как можно больше описаний багов. И здесь мы были вынуждены перестроить работу таким образом, чтобы стабилизировать ситуацию, остаться на плаву и встроить работу над багами в текущий процесс разработки до полного исправления всех ошибок. Мы сделали следующее: ● Все баги тестировщики стали дополнительно анализировать на предмет их взаимосвязи и поиска общих корневых причин, чтобы одним обобщенным описанием убивать несколько багов и уменьшить объем описаний частных случаев. ● Все баги были описаны в эпиках по каждой форме, не в десятках отдельных подзадач, и были пронумерованы. Далее РП производил оценку багов, их приоретизацию и диспетчировал их устранение, согласуя с текущими планами. ● Тестировщики анализировали бизнес-логику вдоль и поперек, делали предложения по ее совершенствованию, моделировали все всевозможные кейсы, всесторонне проверяли и тестировали фичу. Как итог, мы получили новый опыт в QA и очень быстро прокачали нового сотрудника в условиях очень интенсивной работы над проектом и плотного командного взаимодействия. |
Справедливо будет отметить, что организация нашей работы основана не на жесткой вертикальной структуре начальник-подчиненный, а на мягких практически горизонтальных связях, основной движущий силой которых является плотное командное взаимодействие и личная мотивация сотрудников. Структурирующими элементами в этой системе являются “тимлиды”. Они же у нас выполняют роль “тех лидов”.
Исходя из смысла данных ролей, в их основные обязанности входит лидерство в области управления людьми и развития технологий, а именно распределение и учет выполнения задач внутри своей команды, а также принятие технических решений и их согласование с лидами других команд.
Поскольку над каждым проектом работают представители разных команд в формате матричных команд, а проекты часто носят сложный и не тривиальный характер, нередко возникают случаи технических нестыковок, блокеров, белых пятен, зависших вопросов по вопросам взаимодействия компонентов системы, за которые отвечают разные команды.
В результате этого, реализация казалось бы изначального четко и непротиворечиво сформулированного эпиков вязнет в складывающейся неразберихе множества параллельных задач. И по умолчанию именно тим лиды способны реанимировать работу. И в этой связи хочется указать на то, что надо не только называться тим лидом, но реально быть им, по личной инициативе оперативно вникая в сложившиеся трудности и закрывая те белые пятна коллективной работы и технических проблем, которые провоцируют наибольший сбой и перерасход временных ресурсов.
Тим лид именно с такой закваской родился на данном проекте для команды бекенд части бек офиса, что само по себе является огромным достижением проекта.
Жизненные перипетии проекта
Перефразируя название одной из самых лиричных бардовских песен, можно сказать, что “рефакторинг - это маленькая жизнь”. Из этой метафоры следует, что проект рефакторинга, имея определенную эволюционную канву, может быть наполнен неожиданными и не всегда приятными поворотами и перипетиями, которые, как правило, свойственны нашей жизни в этом безумном и непредсказуемом мире.
Как у каждого человека свой уникальный путь, так и сложные, масштабные проекты проходят сквозь непредсказуемые обстоятельства, зачастую далекие от первоначальных планов, если таковые вообще были на старте.
Наш проект прожил местами беспокойную, тем самым весьма увлекательную, но в конечном итоге плодотворную жизнь, которая может быть условно разделена на описанные ниже стадии. Некоторые из фактов могут частично повторяться с изложенным выше, но это только потому, что данная информация является важной, а повторение важного никогда не помешает.
Стадия | Обстоятельства | Эмоциональный контекст |
Начальный энтузиазм | Начало проекта было ознаменовано достаточно быстрой разработкой обновленного макета нового инструмента. Несмотря на достаточно сильную переработку UI макет был оперативно согласован со стейкхолдерами и получил добро на реализацию. Была ясность, как все должно работать. Функционал был описан для разработчиков. В целом на тот момент имелось кажущееся понимание того, что и как нужно делать и даже имелся укрупненный план проекта со сроками. | Сильный оптимизм. Горящие глаза членов команды. Предвкушение быстрой и легкой победы. Полное отсутствие сомнений в успехе. |
Первые трудности | Разработка нового инструмента шла по трем основным направлениям: системная логика, бэкэнд часть бэк-офиса (API, работа с данными), фронтенд-часть бэк-офиса. Первое направление реализовывалось независимо, с некоторыми опережением, и с ним проблем не возникло. Последние два направления шли в паре. Бекэнд и и фронтенд команда договорились о постепенной реализации API от метода к методу. Разработчик бекенд команды фактически приостановил работу над API, т.к. фронтенд команда от него запросила один (или два) метода по главной странице инструмента и стала углубляться в детали разработки соответствующей фронтенд части. Разработка на React вызывала проблемы. Фронтенд команда стала сильно буксовать. Бекенд-разработчик за неимением загрузки ушел в свободное плавание и стал заниматься самообразованием и решением каких-то ведомых только ему архитектурных и технологических вопросов, напрямую не связанных с проектом. Только со временем стало ясно, та работа оказалось ценными инвестициями в будущее. Ее результаты пригодилось впоследствии. По сути, уже на тот момент он решал тех лидерские задачи своей тогда еще не существовавшей команды. Тем не менее на тот момент сам проект стал постепенно выходить из под контроля. Время шло, а быстрых ожидаемых результатов не появилось. А дело тем временем шло к Новому 2021 году. | Оптимизм поубавился. Стало нарастать напряжение ввиду отсутствия запланированного результата. Тем не менее хотелось думать, что вот-вот все наладится, текущие проблемы будут решены и мы быстро завершим проект. В действительности это было самоуспокоение вкупе с непониманием реального масштаба негативных последствий появившихся проблем. Видимо, включилась психологическая защита, вызвавшая подсознательный отказ посмотреть |
Достигли дна | Пробуксовав несколько недель на привязке пары API методов к админке, наконец, пришло осознание, что проект встал и катится в известном для таких случаев направлении. Он явно вышел за ожидаемые рамки и фактически был сорван. С момента старта прошло больше месяца. В сухом остатке имели только мизерную часть API и полуработающего функционала главной страницы инструмента. Данная ситуация была эскалирована руководству. Анализ ситуации показал, что: ● У фронтенд-разработчика (на тот момент одного) появились фатальные трудности в реализации на React (до этого работал на Vue). Работа, оценивающаяся в один день, выполняется больше недели. Начата только первая страница из двух. По факту это составляло 10-15 % от общего объема. Разработчиком были озвучены обновленные сроки по первой странице. Они выглядели весьма оптимистично, но, как выяснилось позднее, занижены в несколько раз. В то же время разработчик предложил руководителю перейти на Vue, обосновав, что это позволит сократить сроки, но это предложение было отклонено, так как шло в разрез с технической стратегией компании. ● По бекенд части результаты в силу вышеозвученных причин ограничились двумя или тремя API методами и только по первой странице. По факту это составляло те же 10-15 % от общего объема API всего инструмента. И все это за месяц с лишним работы. В итоге была поставлена задача в кратчайшие сроки закончить разработку API и с удвоенным рвением продолжить мучить React. Также в команду был добавлен еще один фронтенд-разработчик, чтобы параллельно начать работу над второй страницей. Тогда же мы начали плотную совместную работу в формате самоорганизующейся команды. Планирование работы всех разработчиков стало вестись централизованно РП (аналитиком-координатором) проекта. Митинги стали ежедневными, обсуждение текущего прогресса и проблем - плотным и детальным. С этим мы ушли в Новый год. | Напряжение в команде продолжило расти. Мы еще не отдавали (или не хотели отдавать) себе отчет в происходящем, считая, что в нашем деле трудности редкостью не являются, но выход есть всегда. К тому же забрезжил свет в конце тоннеля - мы сильнее интегрировались как команда с более принципиальным пониманием, что хватит тратить время, пора разделаться с этим проектом быстрее. Появилась здоровая злость. Хоть на самом деле мы и оттолкнулись в конце той стадии ото дна, но еще не знали, что подъем будет мучительно тяжелым. |
На грани отчаяния | Организационные достижения предыдущей фазы дали свои плоды и API была готова достаточно быстро. Да, она дорабатывалась практически на всем протяжении проекта, но это уже были мелочи. Самая страшная проблема раскрылась во всей красе во фронтенд-разработке. Мы просто конкретно встряли по срокам. Мы двигались со скоростью полуживой черепахи. Мы как будто стали участниками бесконечной slow motion сцены в каком-то трагикомическом фильме. И увеличение количества разработчиков не решало эту проблему. Достаточного опыта на React не было ни у кого. Ребята сами учились по мануалам на ходу. В том числе учились на своих ошибках, то есть ценою сроков. Мало того, что время реализации многократно растягивалось, некоторые вещи приходилось переделывать по причине ошибочной реализации. При этом бекенд разработка тоже была постоянно вовлечена в процесс. Помимо API на ее плечах лежали другие важные вопросы - обработка исключений с возвратом ошибок, показ уведомлений о совершенных операциях, доработка серверной логики. Многие вещи делались впервые. Придумывались и тестировались на ходу. Несмотря на всю сложность ситуации мы продолжали работать и делать our best. В тот же период произошла важная организационная трансформация. Изначальное описание функционала инструмента оказалось неудобным для фронтенд-разработчиков. Вместо одного большого описания они хотели иметь декомпозированные задачи, которые они могли бы относительно быстро делать и отдавать в тест. Это было следствием того, что отсутствовал тимлид, который мог бы провести декомпозицию и оформить задачи. Для разработчиков наличие таких задач играло важную психологическую роль. Они могли быстрее получать результат и видеть свой прогресс. Мы договорились, что РП будет создавать и описывать эти задачи по согласованию с разработчиками. Кроме этого, мы стали использовать диаграмму Ганта для визуализации связи между задачами и пути движения к финальной цели проекта. Но проект | Напряжение выросло до пика. Возникало ощущение, что весь мир против нас. Могло даже показаться, что проще и разумнее бросить этот проект, и выйти с наименьшими репутационными издержками для себя, чем продолжать утопать в его трясине. Общий тренд был таким, что команда стала проникаться унынием, а руководство компании - переполняться недовольством. Но мы, стиснув зубы, продолжали делать свое дело и не просто делать, а стараясь совершенствовать нашу работу, насколько это возможно. Мы сосредоточились только на этом, что нас в итоге и спасло. |
Пробуждение силы | Плотное командное взаимодействие, четкая организация работа, быстрое решение возникающих проблем, наглядное и понятное управление задачами принесло свои плоды. В условиях сильно затянувшихся сроков реализации и неодобрительного отношения бизнес-департамента к отсутствию долгожданного результата, руководство компании тем не менее верило в команду проекта и дало возможность довести его до завершения. Самое ценное, что тогда сделало руководство - это не мешало команде, полностью вверив ей проект. Это сыграло ключевую роль, став духоподъемным фактором для всех участников. На этой стадии все стали понимать, что мы делаем “правое дело”, что это, действительно важная и ценная для компании работа. выполнение которой становится все более продуктивной и результативной. К работе активно подключились представители QA. Они практически полностью занимались только этим проектом и были предельно сконцентрированы на нем. Интеграция участников команды была запредельной. Причем, это касалось не только профессионального аспекта, но и человеческого. Именно тогда сформировалась по-настоящему самоорганизующаяся команда. | Эмоциональное напряжение участников команды существенно спало. Стали ощущаться здоровая раскрепощенность. Вернулся энтузиазм. Внимание фокусировалось исключительно на текущих задачах, на их качественном выполнении. Отвлечение на внешние негативные раздражители свелось к нулю. Мы поймали ощущение того, что теперь идем до конца и сделаем так, чтобы нам не было стыдно за финальный результат. |
Стремление к совершенству | На этом этапе мы уже имели значительные работающие куски нового инструмента. Мы уже достаточно ясно понимали, что в итоге у нас получается. Я тогда занял позицию - за оставшееся время разработки постараться создать максимально совершенный продукт. Это означало, что нам нужно было выйти за рамки своего представления о продукте, писанные и неписанные, и уже в процессе работы за оставшееся время непрерывно искать и реализовывать возможности его улучшить. Это касалось абсолютно всего - от косметической шлифовки интерфейса и до адаптации системной логики под наше новое понимание. Как и на всех предыдущих этапах, в тот период продолжилась активная работа со стейкхолдерами. Они были в курсе всего, о чем им имело смысл знать, чтобы иметь возможность внести свой вклад в улучшение продукта. С ними согласовывались все существенные корректировки, их ожидания были предельно сформированы. Работа команды была абсолютно синхронизирована с внешней средой. Мы двигались к релизу с космической скоростью на пределе своих производительных сил. Даже за часы до релиза мы еще доделывали некоторые задачи и выкатывали обновления на тестовую среду. Все таки нет предела совершенству… | Эмоциональная атмосфера в команде приближалась к идеальной. Мы увлеченно творили нечто новое с осознанием высокой важности своей миссии для компании. Присутствовала полная погруженность в процесс, внимание к деталям, широкое видение продукта. Мы заглядывали в будущее. Мы его создавали. И самое главное - команда стала единым организмом. Каждый из нас ощущал себя частью единого целого, и сумма всех нас порождала некое качественно новое образование, внутри которого мы могли гораздо больше раскрывать свой потенциал и резонировать друг с другом. Это то самое волшебное состояние, когда ты кайфуешь от творческого процесса и становишься более счастливым от полученных результатов.
Именно такой она должна быть атмосфера, чтобы команды создавали гениальные продукты. Быстро, непринужденно и с высокой внутренней мотивацией. |
Долгожданный релиз | Это был один из самых ожидаемых и волнительных релизов в моей жизни. Могу предположить, что не только в моей. Созданный за несколько месяцев работы достаточно крупный кусок нашего продукта ожидал своего выхода в продакшен. Итог оказался весьма скучным. Поставка прошла успешно, новый инструмент обрел новую жизнь, живет до сих пор и постоянно совершенствуется, избавляясь от недостатков и обрастая новыми фичами. | Напряжение опять возросло. Как обычно в таких случаях в воздухе витал страх перед возможной неудачей. Но глаза боятся, а руки делают. Первое чувство, испытанное после релиза, было не восторгом и радостью от запуска нового инструмента, а облегчение от того, что мы освободились от груза громадной ответственности, связанной с его созданием Хотя затем по мере того, как улеглись первые эмоции, пришла вполне обоснованная и заслуженная радость. |
Безусловно, не все проекты в нашей компании столь эпичны. В данном случае в силу большой продолжительности и высокой сложности проект вобрал в себя очень много составляющих по различным аспектам, стал собирательным образом. Он подобен фракталу, включающему в себя черты всего того, что его окружает. Глядя на него, мы можем видеть то, как работает вся компания, как реализуются другие задачи и проекты.
Ретроспектива
Любая деятельность в нашей жизни требует осознанности. Иначе не будет ни полезного результата на выходе, ни качественного развития в процессе. В современном IT-мире существует практика проведения ретроспектив, которая призвана вносить эту самую осознанность в мышление людей и рабочие процессы.
Накануне релиза мы провели сессию-ретроспективу с участием всей команды проекта и руководства,. Естественно, практически добравшись до финиша спустя несколько незапланированных месяцев после старта проекта, команда жаждала восстановления справедливости объективного отношения к произошедшему. И в первую очередь, этого жаждал РП, который непосредственно отвечал за сроки проекта и качество продукта.
Требовался детальный разбор ошибок и достижений, их причин и следствий. В итоге ретроспетива прошла очень продуктивно и решила все эти задачи. Мы глубоко и детально разобрали плюсы и минусы проекта, зафиксировали личные и командные результаты, сделали выводы о масштабировании ряда практик, принятии корректирующих воздействий. В сухом остатке мы сделали два важных вывода:
Каждый участник сделал максимум возможного. Даже, если совершались ошибки, то они быстро устранялись, но и по ходу проекта работа целенаправленно совершенствовалась в динамике.
Ключевую роль в реализации проекта сыграл тот самый РП, он же аналитик-координатор. Конечно, без него проект тоже мог быть каким-то образом реализован. Но в том-то и дело, что “каким-то” - гораздо медленнее и с низким качеством. В данном случае мы говорим о позитивных изменениях, обусловленных ролью РП.
Все участники проекта признали, что имеющиеся командные результаты достигнуты во многом благодаря эффективной организации работы. РП обеспечил планирование проекта, ясность требований для участников, устранение блокеров процесса разработки, синхронность действий участников, релевантность результатов внешней среде, ожиданиям стейкхолдеров. Это человек связал все составляющие проекта воедино и направил этот монолит в одном направлении. И все это неудивительно. РП существуют, чтобы делать делать проекты успешнее.
В нашем случае аналитик с хорошими организаторскими способностями стал тем членом команды, который выполнил нужные для компании функции РП. Он способствовал созданию продуктивной рабочей обстановки на проекте, в условиях которой потенциал всех участников смог раскрыться в максимальной степени. Эту модель РП мы продолжаем применять и развивать в своей работе.
Резюме
Этот проект придал компании довольно сильный эволюционный импульс. Компания стала меняться благодаря ему, причем, в некоторых аспектах довольно значительно. Рефакторинг продукта спровоцировал рефакторинг самой компании. Он раскрыл глаза на многие важные моменты и преподнес немало уроков. Лично я стал смотреть на свою дальнейшую работу в том числе через призму этого проекта, обнаруживая много параллелей с ним и развивая те организационные идеи, которые были высвечены по его результатам.
В следующей части статьи будут представлены некоторые рекомендации о том, на что имело бы смысл обратить внимание не только при реализации подобных проектов, но и в ежедневной работе. Все это - не какой-то структурированный и последовательный алгоритм или управленческая система, а квинтэссенция идей и взглядов на определенные моменты рабочего процесса и проектного управления. Будут выделены именно те моменты, которые могут оказать существенное влияние на результаты и эффективность работы, качественное развитие всех ее участников и компании в целом.
