Новый 15-летний проект без команды и документации: как мы выжили
Я когда-то читал, что группы людей, которые попали в экстремальную для жизни ситуацию, чаще умирают в том случае, когда ожидают помощи извне и не принимают самостоятельных попыток спасения. То же самое происходит и с командами, когда есть проблема, но решение хотят получить от кого-то другого — менеджера, клиента, руководителя проекта, бизнес-аналитика, Stack Overflow или кого-то еще, — но только не искать его самим.
Итак, это история о том, как мы выживали, когда не ясно было, как выживать. Сразу скажу: не пытайтесь это повторить...
Закон Мерфи
Зимой 2016, когда мы с женой поехали в круиз на Карибы, по возвращении я приехал в офис хорошо отдохнувший, без особого желания напрягаться после отпуска. Все было довольно предсказуемо: мы выдали релиз перед Рождеством, ошибок обнаружено не было, да и свой проект я знал досконально. Но законов Мерфи никто не отменял: если все идет хорошо, значит вы что-то упускаете. В обед мне назначили митинг у Senior Director, но ничего не предвещало беды...
Все прошло быстро. Мне сказали, что я больше не занимаюсь своим основным проектом и что с сегодняшнего дня я работаю над другим проектом, который достался компании в результате поглощения. Проекту уже более
Любой нормальный человек подумал бы об увольнении, но уволиться я не мог. Было два пути: либо плакать и страдать, либо думать и делать. Пришлось идти вторым путем.
Думать и делать: кто нужен в команду
Первое, с чего пришлось начать, — это формирование команды. Но самое интересное, кто нужен в команду — было не ясно.
Многие менеджеры скажут, что нужно было согласовать KT (Knowledge Transfer) plan или что-то подобное, и, конечно же, он у нас был. Но план хорош, когда его готовы выполнять, а выполнять программисты из Коннектикута его не хотели и не собирались.
В конце февраля все трое программистов приехали к нам в офис. Мы провели для них презентацию, рассказали о своем текущем продукте, процессах, деплойменте, архитектуре. На что они нарисовали нам диаграмму на бумаге, потом на Surface открыли приложение, показали и поехали обедать. Было явно видно, что никто не готовился и готовиться не собирался.
Я поехал поговорить с ними за ланчем. Они рассказали мне, как получают звонки от клиентов о том, что система списала деньги с аккаунтов, но при этом кредиты не зачисляются в системе, и еще много такого, от чего у меня носки сползли в кросовки... После этого ситуация стала совсем печальная.
Как впоследствии окажется, архитектура системы напоминала мне паутину. Было понятно только, что есть ядро, написанное на .NET 2.0/4.0 на базе COM/DCOM технологии, был API, написанный на ASP-Classic, и VB 6.0, интегрированный с ядром посредством COM-компонентов, а также фронтенд, написанный на HAHTSite Scenario Service (Java) cо своим скриптовым языком, с вкраплениями jQuery/Bootstrapper и т. д. Что-то ходило в базу через .NET SQL, что-то через OBDC, что-то через Microsoft Access. Все это было приправлено интеграцией с внешними библиотеками обработки пространственных данных MapInfo/MapXtreme и многим другим.
В целом система представляла из себя конструктор, на базе которого можно было построить огромное количество различных репортов по оценке рисков, геопозиционированию и обработке пространственных данных и многому-многому другому.
Команда и работа
Стало ясно, какая команда нужна, и выглядела она так: четверо программистов с нашей стороны с хорошим знаниями .NET, а также знаниями VB6.0 и опытом работы с пространственными данными. К работе подключили BA с нашей стороны, поскольку проект не содержал вообще никакой документации. То есть за 15 лет никто не удосужился вообще что-то задокументировать. В команду включили QA, потому что было не ясно, как вообще можно проверить эту систему на работоспособность, начать ее менять и мигрировать.
Со стороны клиента нам назначили BA, которая сидела в Чикаго, PM, который сидел в Лос-Анджелесе, Product, который сидел где-то в Коннектикуте, и одного Release-инженера, который сидел в одном кубике со мной.
Клиентский бизнес-аналитик ушла через месяц после того, как оказалась на нашем проекте, привнеся больше хаоса, шума и беготни, чем пользы. Формализация артефактов и вся работа по формированию документации легла на плечи нашего BA. Это был первый камень с моих плеч. По крайней мере, если бы она не ушла сама — мне бы пришлось думать, как сделать так, чтобы на проекте ее не было. А тут такой подарок...
Наш бизнес-аналитик справилась отлично, но чего ей это стоило, наверное, сможет написать только она. Как она выстраивала логику работы, описывая все на бумаге, собирала информацию по крупицам.
«Самый медленный верблюд»
Стоит еще сказать о release-инженере на стороне клиента, так как это отдельная история. Есть старое утверждение, что «караван идет со скоростью самого медленного верблюда». Так вот, релиз-инженер не стороне клиента был не просто медленным верблюдом, он был гирями на моих ногах. И вот теперь стояла задача избавиться от него, но при этом сохранить дружеские отношения, не показать клиенту, что он не справился со своей работой, потому что на другом проекте он ведет весь деплоймент. То есть конфликтовать было нельзя, а работу он свою явно не тянул.
У него была идея разбить все на модули, сделать компонентный деплоймент. Отлично, это ему и поручили. После двух недель мозгового штурма у него стали закипать мозги от проекта: он пытался билдить проект и полностью, и частично, и покомпонентно — UI отдельно и back-end отдельно. Когда идеи исчерпались, он сказал, что development team должна разобраться и предоставить ему исправление ошибок билда. Я думаю, для многих знакомая ситуация — когда во всем должны разобраться программисты. Но пойдем дальше.
Так и было сделано, я ему отправил пояснения его ошибок и пошел дальше работать. Указав при этом руководству, что не могу выделять больше времени на разработку стратегии релиза, потому что есть текущие более критические задачи. Ему пришлось снова уйти в мозговой штурм на неделю или две. В общем после десяти вот таких итераций, а также мягкого намека руководству, а еще и после того, как появились сложности с релизами на других проектах, наш клиентский release-инженер сказал: «Не могли бы вы это взять на себя?». И героически ушел решать проблемы, «созданные им же самим».
Я, конечно, сказал, что мы постараемся, что у нас нет времени, но мы подумаем, как это можно сделать. Но на самом деле это мне и было нужно: «самый медленный верблюд» решил уйти в пустыню и там спокойно умереть, он выбрал это сам. Слезы благодарности лились из его глаз, когда мы позволили ему это сделать. Но вернемся с системе..
Первый программист уволился в конце марта
Первый программист оставил после себя чистый ноутбук с исходным кодом неизвестно какой давности, но явно не той, что была на серверах.
Как только мы получили хоть какой-то исходный код системы, мы сразу начали строить диаграмму зависимостей. В целом это довольно монолитная система, но нам удалось выделить блоки и понять, с чего начинать билдить проект и как модули связаны между собой.
Кстати, на мое замечание о связанности системы мне четко ответили, что система, доход которой исчисляется несколькими десятками миллионов долларов, не может быть плохой :) И вот как парировать такой аргумент? Да никак. Вы можете только взять и сделать так, чтобы она приносила еще больше прибыли.
После того, как прояснилась структура, стало понятно, откуда начать «пилять проект». Мы разбили процесс на блоки, написали билд-скрипты под MSBuild и в результате получили возможность собирать проект по необходимости и частями. Да, пока это была просто сырая версия, но она позволяла нам собрать пакет, выложить его, задеплоить в ручном режиме и проверить.
Второй программист ушел в апреле
Работу пришлось разбить на несколько частей. Я занялся полностью суппортом, так как другого способа просто не было. Никто лучше нас систему не знал, ни у кого не было понимания, как работает код и как можно поддерживать более 40 тыс. аккаунтов с более чем 6000 конфигураций на существующих 23 серверах. Двое ребят в Киеве начали разбираться в GUI и API, параллельно пересаживая его на более стабильную и современную платформу. Один человек занялся рефакторингом существующего ядра. BA начала работу над документацией: как система работает, какие есть конфигурационные настройки и как они влияют на работу приложения. QA занялся покрытием системы интеграционными тестами, разработкой тест-планов и стратегией тестирования.
Третий программист... на него я зла не держу
Третий программист, который в основном занимался конфигурированием системы, смог провести ряд сессий и как минимум предоставить нам базовую информацию, как работает система и как построен процесс конфигурирования в системе. Он уволился в июне... на него я зла не держу.
Начиная с апреля, моя работа состояла в том, чтобы прийти утром — выписать на доске проблемы, которые я планирую решить, и в течение дня менеджер просто подходил и расставлял на доске приоритеты. Никой Jira, TFS или Trello. Есть проблема — подходите, пишете на доске ее номер и все. Я знаю, что ее нужно решить раньше, чем проблему под ней. Затраты на коммуникации практически свелись на нет, так как объем приходящих проблем был просто колоссальный. Я мог в день закрыть 30 багов и на следующий день проснуться с еще
Подходим к стабильной стадии
К осени у нас уже был рабочий прототип UI, написанный на Angular + ASP.NET MVC, документация и что самое главное — понимание, как работает система. И все казалось не таким страшным, но клиент решил отказаться от нового UI, сохранить сервера на Windows Server 2003 и попытаться мигрировать существующую систему в новый data-центр. И моя жизнь опять приобрела темный оттенок.
В нашей компании более 20 тыс. человек. И когда я попытался поискать кого-то с навыками работы c HAHTSite Scenario Server, я нашел только одну девочку, которая добавила это в описании своего проекта, еще когда пришла джуном, и даже не могла пояснить, что это значит и как это работает. Bот такой легаси код, пацаны...
Документацию по HAHTSite мы выкачали где-то на китайских сайтах, как и документацию по остальным компонентам. Компоненты работы с пространственными данными уже не поддерживались производителем, и клиент не хотел платить за лицензию. Я вспомнил VB 6.0, который учил еще на 2 курсе университета, и вы даже не представляете, что значит найти рабочий инсталлятор VS 6.0. Я научился реверс-инженерить программы, когда ты запускаешь код и просто с помощью Process Explorer-а видишь, как выполняется программа, что она берет из реестра, какое событие она передает, какую переменную инициализирует, смотришь через WireShark, куда отправляются пакеты и что возвращается обратно. Это магическое зрелище... и нудное одновременно.
В результате
На сегодняшний момент проект вошел в стабильную стадию, продукт стабильно генерирует миллионную прибыль ежегодно и масштабирован на нескольких десятках серверов. Потратили мы на проект около 2 лет, а на более-менее стабильную стадию мы вышли через
КОМАНДА — ЭТО ВСЕ!
Меня часто пытаются убедить, что процессы главнее, что все заменяемо и что менеджмент — это главное, а исполнители нет. Но сделал бы я этот проект с другими людьми? Я думаю, нет.
Спасибо ребята! Вы лучшие!
Советы
Статья будет неполной, если я не скажу, что делать, если вам «повезло» попасть в подобный проект. Честно — я бы рекомендовал начать искать другую работу. Такой проект очень выматывает, требует большого количества внимания и координации, много времени на анализ, понимание структуры и архитектуры проекта. И основное, конечно, — вы не знаете, какой технический опыт вам нужен и как он пригодится в дальнейшем. Но все, что не убивает, делает нас сильней. И если вы сделали такой проект — после этого вам не будет страшно уже ничего.
Вот советы, которые я бы дал (постараюсь избегать общепризнанных очевидностей):
Убедитесь в адекватности клиента вообще. Если клиент вам доверяет и понимает, что вероятность провала высока, и при этом дает кредит доверия, то практически половина работы сделана.
Решайте проблемы сами и не эскалируйте каждую мелочь наверх. Но если что-то реально серьезное, не пытайтесь решить своими силами — сразу звоните в колокола.
Начните как можно активнее собирать информацию — документы, сессии, встречи и все остальное, что позволит вам разобраться в будущем. Желательно сделать копии баз данных, репозиториев, исходного кода, пакетов и т. д., потому что программисты в случае конфликта могут нанести довольно серьезный ущерб.
Всегда планируйте с запасом. Даже если вы сэкономите время на одной задаче, вы его с лихвой потратите на другую.
Не переносите панику клиента в команду. Люди очень быстро выгорают на таких проектах. Старайтесь находить интересные задачи. Поддерживайте хорошие отношения с командой. Поверьте, вам придется их просить о многом и часто.
Поймите клиента. Если клиент говорит, что это важно, постарайтесь понять, почему. У нас была небольшая ошибка, и нам стоило полдня исправить ее и выкатить билд. Но в силу того, что эту функциональность использовала государственная организация и только из-за этой ошибки она пометила клиента как ненадежного поставщика данных, и поскольку у клиента огромное количество продуктов используется в государственных органах — такая метка могла стоить им миллионы.
Вовлекайте команду в общение с клиентом. Это, с одной стороны, разгрузит вас от задач по коммуникации, с другой — позволит команде участвовать в процессе и держать руку на пульсе. В общем не старайтесь быть «бутылочным горлышком».
Разбирайтесь в системе сами. Вы должны уметь программировать, построить полностью процесс, пофиксить ошибку. Возможно, не с такой скоростью, как любой из членов команды, но вы должны это уметь и понимать, как это можно сделать.
Старайтесь внедрять новые практики в проект. В нашем случае клиент не понимал, зачем строить CI/CD, и предлагал не тратить на это время сейчас. Мы выделили на это время за счет других задач и построили систему локально, потом перенесли ее на сторону клиента. Когда стала задача, что нам нужен CI/CD, — у нас он уже был, и клиент остался доволен, хотя, по сути, он за это заплатил за счет других задач.
Также старайтесь, чтобы программисты работали локально. Я не знаю, откуда взялась тенденция заставлять людей работать через RDP, — но это просто убивает желание работать на корню. Все должно быть локально и по возможности автоматизировано. Это позволит вам понимать систему как никому другому. Если вы можете поднять систему локально, это значит, что вы ее знаете досконально.
Выбивайте рост ЗП. Такие кризисы — хороший вариант поднять себе ЗП или пересмотреть должность. Когда в системе все неспокойно, вам готовы дать все — лишь бы вы решили проблему.
Учитесь другим технологиям, пока работаете над проектом. Когда вы уволитесь — все ваши знания будут никому не нужны :) Но когда вас спросят, можете ли вы работать в критической ситуации, — вы точно будет знать, чего это стоит и сколько за это просить.
