Строим дом удалённо или Как не завалить IT-проект

Строим дом удалённо или Как не завалить IT-проект

Рис 1. Измученный заказчик пытается управлять стройкой дома (IT-проектом)

Я уже писал о том, чем полезен внешний CTO в IT-проекте – здесь (о проблемах) и здесь (о решении).

А сегодня мне пришла классная аналогия того, как я работаю с IT-проектами в роли внешнего CTO с 25-летней экспертизой в разработке.

Уверен, вам понравится, потому что я получил от этого кайф) Поэтому рассказываю:

Аналогия со строительным надзором#

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

Его приглашают на строительные объекты для того, чтобы убедиться, что всё идёт нормально. Когда не хватает компетенций или других ресурсов делать это самим.

Пример со стройки#

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

Понятно, что если раньше он таких управленческих задач не решал, то ему будет непросто.

Ведь нужно компетентно решать следующие задачи:

  • объективно оценивать темп работ
  • проверять, что не обманывают
  • следить за качеством

Удалённая стройка#

А теперь представьте, что делает он это полностью удалённо. То есть, у него нет возможности:

  • проверять качество на ощупь
  • визуально оценивать геометрию
  • делать замеры
  • чувствовать запах материалов

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

А что в IT-проекте?#

Но прикол в том, что описывая гипотетическую ситуацию для стройки, я только что описал реальную и очень распространённую сегодня ситуацию для IT-проекта.

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

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

Но на самом деле это огромная иллюзия.

Простота – это иллюзия#

Наблюдая за проектами, я вижу, как:

  • недобросовестные разработчики делают ненужную работу, имитируя крайне необходимые проектам действия
  • слабые специалисты сидят на неоправданно высоких ставках, выдавая слабые результаты и сжигая бюджеты
  • работа идёт медленно, и заказчик это терпит, не зная, как это должно выглядеть в идеальном случае
  • качество кода и архитектуры оставляет желать лучшего, и репозиторий быстро превращается в свалку костылей, сделанных наспех (я не шучу)
  • члены команды отваливаются от проектов, унося с собой не только экспертизу, но и наработки - с их уходом проект теряет фрагменты кода или сопутствующих инструментов - скрипты, данные и даже целые подпроекты, которые по разным причинам не попадают в центральный репозиторий
  • задачи не выполняются неделями и месяцами, сроки горят, релизы не происходят
  • лезут бесконечные ошибки
  • требуются неожиданные доработки там, где, казалось бы, всё давно уже работало - так проявляется технический долг
  • в конечном счёте проект умирает, не в силах тянуть столь неэффективную разработку

И это лишь малая часть того, с чем я сталкиваюсь и что обычно вижу невооружённым взглядом. По сути, выполняя “строительный” надзор за IT-проектами.

Как можно иначе?#

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

  • процессы выстраиваются
  • темпы вырастают
  • инструменты внедряются
  • коммуникация улучшается
  • код и архитектура становятся чище

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

В чём собственно суть#

А всё дело в том, что строителями должен управлять строитель, а разработчиками разработчик. Иначе не работает. Как ни крути. Проверено многократно.

За 25 лет в разработке видел всякое (здесь описал свой путь в IT, а здесь представился).

Могу стать вашими техническими глазами в вашем IT-проекте. Осуществлять надзор и/или техническое управление. Выстраивать процессы и системы, прозрачно, измеримо и управляемо.

Почувствуете эффект с первой недели сотрудничества! Гарантирую.



Авторы

Logo Юрий Абдуллин @yury_ea
CCO/CTO, IT-предприниматель, ментор IT-стартапов.
25 лет в разработке информационных систем (обо мне)


Открыты к новым проектам

Выполняем профессиональную разработку информационных систем, сервисов и платформ:

  • дорабатываем MVP до полноценных систем
  • проектириуем и внедряем ИИ-агентов
  • проводим аудит кода и процессов
  • обеспечиваем качественный QA и DevOps

Выполненные проекты IT/AI-интегратор Заказать разработку