В 2020 году нас всех накрыл Covid-19 и все засели по домам. Во время самого жёсткого локдауна у меня было разрешение ездить на работу, т. к. я работал в сфере, которая это позволяла. Но при этом у меня истекал срок действия прав, а продлить я по причине локдауна не мог. Несмотря на то, что правительство официально разрешило ездить с просроченными правами до июня, а потом и до сентября, когда меня остановила полиция и проверила мои документы – мне таки сообщили, что права просрочены и знаю ли я об ответственности. Я сказал, что всё знаю и давно бы продлил права, если бы эти бравые парни из ГИБДД открыли приём населения.

Для меня это стало неприятным сигналом и как только ГИБДД стали принимать посетителей на замену прав, я сразу записался, получил справку и заменил права. Во всём этом была одна интересная деталь, в медицинской справке, которую я получил было разрешение на получение прав категории Б и А. Стоит отметить, что я с юности мечтам открыть категорию А и ездить на мотоцикле, но сначала не было денег, потом времени, а потом жена не одобряла.

И вот сидя в ГИБДД и ожидая приёма, я от скуки стал рассматривать пакет документов и ту самую справку. После чего решил всё-таки попробовать ещё раз поговорить с женой насчёт категории А, справка то вот есть… ну открою категорию, но это не значит, что я сразу куплю мотоцикл.

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

Я радостно записался в мотошколу, где меня несколько раз спросили, точно ли моя справка позволяет открыть категорию А и уже при моём лично визите убедившись в этом, меня записали на курсы.

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

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

Одна из ключевых проблем многих мотоциклистов, при том не только новичков – это работа со взглядом. Тело старается тянуться за направлением взгляда, как только вы повернули голову и сосредоточили взгляд на каком-то объекте, мозг начинает ориентировать и тело по направлению к этому объекту.

Когда вы едете на мотоцикле и смотрите под ноги, на приборную панель, руки, на асфальт перед передним колесом и перед вами стоит задача проехать поворот – с вероятность 95% вы это не сделаете. Или сделаете, но очень коряво, корректируя себя уже в процессе прохождения поворота и успех будет зависеть от случайных факторов, скорости мотоцикла, вашей реакции, крутизны поворота, качества покрытия и так далее.

Поэтому одним из основных навыков, которыми вы должны овладеть – это правильный взгляд. Смотреть нужно не туда, куда вы едете, а туда, куда вы хотите попасть.

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

Особенно ярко это принцип мне объяснил один инструктор, который сказал мне, чтобы удачно пройти поворот, старайся не просто смотреть в поворот, а как бы пытаться заглянуть за него. Тогда, ты сможешь увидеть проблему в виде ДТП, пробки или ямы чуть раньше и у тебя будет больше шансов предпринять корректирующие действия.

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

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

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

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

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

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

Тем временем я вместе с архитектором проекта и лидом разработки рассматривали мой roadmap, делали примерные оценки сроков и восхищались стройностью roadmap, который вместо дёрганного проектирования смежников имел чёткие и понятные границы.

В этот момент вернулись смежники и сообщили, что ПСИ не прошли и теперь всё надо переделать по-другому. Тут стоит сказать, что это уже был второй раз, когда функционал надо было переделать. При том сейчас, нужно было передать версию 2, в то, как было сделано в версии 1 на 90%. Надо сказать, что архитектор был в ярости, он кричал, говорил нет, мы так делать не будем! Я же тебя спрашивал, точно ли это то, чего хочет заказчик? Иди договаривайся, мы не будем переделывать! И так далее…

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

Но roadmap у команды остался и когда спустя несколько месяцев им на 100% выделили команду разработки, они несколько месяцев смогли реализовывать этот roadmap, и он при этом, не потерял своей актуальности для заказчика.

Второй случай произошёл уже в 2018-2019 годах, когда я в качестве архитектора решений внедрял CRM систему в одного телеком оператора. На проекте использовать методология blueprint, т. е. мы взяли готовое решение заточенное под одного западного телеком оператора, сравнили его с потребностями клиента и решили внедрить его с минимальным уровнем доработок. Т. е. считалось, что 80 и более% функционала будет переиспользовано. А раз так, на проект выделил 4 месячных спринта, чтобы допилить решение до потребностей клиента.

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

Получилась вот такая матрица:

Такое представление помогало решать сразу ряд задач:
1. Команда знала, что к каком моменту нужно спроектировать и разработать
2. Руководство проекта видело, чем мы планируем заниматься в ближайшее время
3. Заказчик видел ход реализации и понимал, когда будет полноценно реализован тот или иной сценарий
4. А команда тестирования понимала, что войдёт в состав демо.

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

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

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

Бороться с клиентом самое последнее дело, которое не приносит пользы не одной и сторон конфликта, но используя технику «Заглянуть за поворот», я нашёл подход к клиенту и смог убедить его в пользе сотрудничества, но об этом я расскажу в другой статье.

В качестве резюме этой главы – старайтесь выработать в себе привычку «Смотреть за поворот», так например:

1. Что будет с этим решением через год? А через два?

2. Какие требования смогут сломать систему?

3. А что будет если через полгода нагрузка на БД вырастет в двое?

4. Какие слабости и костыли мы приняли в процессе проектирования?

5. Насколько сложным будет масштабирование?