Почему разработка программного обеспечения тесно связана с бизнесом и деньгами
Уже 20 лет я занимаюсь разработкой и техническим руководством. Помогаю проектам решать проблемы с доступностью, скоростью разработки и масштабированием.
Эта статья — о процессах жизненного цикла разработки программного обеспечения на языке бизнеса и денег. Руководители многих проектов ждут от инженеров простые ответы на сложные технические вопросы и не получают их. В то же время технически все проекты похожи и решение большинства проблем известно. В этом материале я обобщаю свой опыт общения с руководителями разных компаний, когда ответов короткими фразами было недостаточно. Надеюсь, это заметка поможет представителям бизнеса и инженерам лучше понимать друг друга.
Однажды прораб обсуждал с потенциальным заказчиком ремонт небольшого дома. Владельца беспокоило, что стены накренились. Дом был сложен из кирпичей, кирпичные стены просто стояли на земле. По всему периметру дом укрепляли деревянные подпорки, но стены так и норовили обвалиться.
— Ваш дом в аварийном состоянии, требуется реконструкция, — сказал прораб. — Мы протянем силовой кабель, чтобы запитать оборудование, выроем котлован, сделаем водоотведение, зальем фундамент...
— Нет, нет! — прервал его владелец дома, — мне не нужен котлован, мне нужны стены! Дом!
— В таком случае, может, вы подумаете о покупке модульного дома? — предложил прораб.
Иллюстрация Уляны Патоки
Наше время
Как руководитель команды разработчиков в прошлом месяце я общался с основателями одного стартапа. У стартапа есть работающий веб-сервис, который разные люди писали несколько лет, и теперь руководство думает, что с ним делать. Основатели рассказали мне о своем желании нанять команду из десятка разработчиков, чтобы переписать или модернизировать приложение. Я спросил про User Story, документацию, трекер задач, но этого не было. И владельцы попросили составить список того, что я предлагаю сделать. Я написал вот это:
- Перечислить ключевые параметры, которые влияют на продажи: SLA, функционал — что угодно, чтобы привязать виртуальные задачи к реальному миру.
- Определить контексты по DDD и создать высокоуровневую документацию, чтобы обсуждать архитектуру и помочь новым разработчикам осваиваться в проекте.
- Определить узкие места системы, которые вызывают проблемы с масштабированием и доступностью.
- Согласовать среднесрочные цели IT-команды с высшим руководством.
- Создать рабочий процесс на инструментах командного взаимодействия таких, как доска, трекер, мессенджер, репозиторий.
- Организовать процесс найма и вхождения в проект новых разработчиков.
- Наладить системы мониторинга и бэкапа.
- Декомпозировать среднесрочные задачи по этапам и написать календарный план.
- Сделать CI/CD.
- Написать план изменения архитектуры.
- Выставлять приоритеты задачам в бэклог.
- Наладить регулярные встречи IT-команды с продактом и отчеты высшему руководству.
А где разработка? Ответ — весь список. Это называется жизненным циклом ПО.
Владельцы стартапа сказали, что им не нужен менеджмент, им необходима операционная деятельность. Спасибо добрым людям за отзыв. Он навел меня на мысль написать статью и подробнее рассказать, что такое разработка и почему перечисленное по большей части не относится к управлению.
Все перечисленное связано с деньгами.
Как элементы списка связаны с бизнесом и деньгами
Ключевые параметры, которые влияют на продажи: трафик, конверсия, возвраты, сколько клиентов возвращается, сколько уходит и так далее. Мы все любим исследования, обсуждать культуру разработки, спорим из-за стандартов, но оценка IT-компаний — это произведение годовой выручки или размера клиентской базы на мультипликатор, и код не принимается во внимание. Задачи разработки должны быть привязаны к важным измеримым параметрам бизнеса.
Я принимал участие в разработке множества проектов и помню несколько случаев, когда владельцы-управляющие растущих проектов игнорировали серьезные изменения ключевых параметров. Один проект терял трафик из-за конкурентов, у другого выросли возвраты денег за оплаченные покупки. Игнорирование этих проблем разрушило проекты всего за несколько месяцев после многих лет работы. Несмотря на то, что технически они надежны и до сих пор приносят небольшие деньги, доля рынка потеряна навсегда.
Обратную ситуацию я помню в корпорации Oracle. Каждому сотруднику — разработчику, тестировщику, менеджеру — рассказывали о том, сколько миллионов долларов выручки у продукта, над которым они работали, какая рыночная доля, сколько клиентов пришло, сколько осталось, кто конкуренты и так далее. Были общие собрания, на которые приезжали вице-президенты и готовили для коллектива тот же доклад по результатам, что и для совета директоров. Как можно видеть по отчетам Oracle, такая концентрация на результатах работает очень хорошо.
Бизнес-логика — хороший критерий разделения системы на модули и сервисы. Определение контекстов помогает людям понимать друг друга, уменьшить потери времени в общении и определить зоны ответственности. Кроме того, изучение логики приложения — часть процесса найма новых сотрудников. Инвестиции в высокоуровневую документацию окупаются с каждым новым работником, модулем системы и сервисом.
Узкие места системы — это проблемы, которые мешают достижению целей по ключевым параметрам. Их нужно отразить в задачах в бэклоге и учесть в планах разработки.
Среднесрочные цели — это то, за что компания платит сотрудникам IT-подразделения. Писать планы — не критично для выживания компании, но их отсутствие обычно означает, что разработчики только играют в исследования и спорят о стандартах, но мало времени уделяют тем задачам, которые повлияют на бизнес.
Процесс разработки с доской, трекером задач, системами контроля версий, совещаниями, проектированием, code review, сборкой, тестированием и выкладкой — естественный для большинства команд. Мы просто не можем предсказуемо и постоянно выкладывать в работу задачи и соблюдать SLA — процент времени доступности системы, без надежного процесса разработки.
Все инструменты уже подготовлены, настраиваются за пару дней, бесплатны или недорого стоят. Jira или Clubhouse, Slack/Element/Riot/Skype, GitHub или GitLab, Jenkins/Actions/Jobs, Docker Registry, Swarm или K8s, Sentry/Rollbar/Logstash — все уже сделано, надо выбрать и применять.
О найме. Почти все в проектах делают наемные сотрудники. Нужно ли делать найм многоступенчатым и сложным процессом или руководство будет нанимать людей на нерегулярных интервью, зависит от планов бизнеса. Проверка гипотез и масштабирование требует разных специалистов. Активно растущим стартапам необходим процесс с минимальным участием высшего руководства.
Стоимость адаптации — это сумма зарплат сотрудников, которые обучают, плюс недополученная прибыль от задач, которые не выполняют специалисты во время обучения новых сотрудников. Крупные корпорации могут позволить себе несколько месяцев на вхождение нового программиста в проект. Однако большинству проектов нужно, чтобы сотрудник начинал выполнять задачи как можно быстрее.
Относятся ли в компании к найму как к процессу или это разовые события — простой показатель планов компании расти.
Мониторинг систем, протоколирование, планы резервного копирования и восстановления — это не первоочередные задачи, которые нужно выполнять при запуске MVP. Это становится выгодно, когда проект начинает тратить деньги на привлечение клиентов. Все однажды ломается, и чем больше бюджет, тем важнее становится способность системы обслуживать поток денег непрерывно. Резервные копии данных — это не управленческое решение, это естественный способ сократить простои.
Декомпозиция среднесрочных планов по этапам и эпикам нужна, чтобы сделать разработку предсказуемой, быстрее узнавать о проблемах и решать их. Это необходимо, чтобы сокращать простои сотрудников из-за проблем, которые от них не зависят.
Выгода от непрерывной разработки и непрерывной доставки (CI/CD) не очевидна. По закону Лемана, сложность программного обеспечения увеличивается вместе с развитием системы, если не контролировать это. CI/CD — усилия команды разработчиков по сдерживанию увеличения уровня сложности. Покрывая код тестами и запуская их на стендовых серверах при сборках, мы сдерживаем увеличение затрат на разработку. Эта задача оправдана только для растущих и успешных проектов.
Для большинства обычных проектов достаточно выкладки из релизной ветки Git. Если растем без CI/CD — тоже ничего страшного, однако нужна команда QA такого же размера, как команда разработчиков. Удваивается площадь офисов, количество техники и менеджеров на совещаниях. Проект будет медленнее развиваться, но на растущем рынке можно не замечать этого годами. Я знаю несколько крупных проектов без тестов, в каждом тратят сотни тысяч долларов в год на переписывание тех частей кода, которые не были покрыты тестами.
План изменения архитектуры — это одна из самых важных задач из тех, которые позволяют ускорить разработку функционала, что может серьезно повлиять на бизнес и масштабировать успешную модель. Благодаря этому плану можно расставить задачам верные приоритеты. Но он не нужен для поддержания работоспособности системы. План нужен, когда есть амбициозные цели на серьезный рост и соответствующие ресурсы. Это не управленческая задача, это задача сотрудника на позиции архитектора.
Выставлять приоритеты задачам в бэклог можно по-разному, нет единого правила для всех. В методологии SCRUM приоритеты выставляет команда на planning-совещаниях. В традиционных моделях приоритеты выставляет руководитель команды. У руководителя-чайки нерегулярность изменения приоритетов приводит к их отсутствию. Людям удобнее работать, когда они знают правила определения важности задач. Тогда учатся выполнять более приоритетные задачи, чтобы чувствовать себя важными.
Регулярные встречи с руководством, отчеты лицам, которые принимают решения, и внимание позволяют людям чувствовать, что они правильно поступают, ощущать себя частью чего-то большего. Это помогает команде пережить кризисы.
Сколько стоит сделать стартап
Итак, сколько времени займет проект? Чаще всего ответ надо рассматривать в разрезе «возьмите WordPress, как поступили 38% веб-сайтов в интернете». Зачастую задачу вроде «сделать сайт» можно решить без команды программистов. Использовать SAAS, взять коробочное решение или отдать задачу на аутсорс и получить конечную цену решения. Кроме случаев, когда вы строите бизнес в IT. По законам Лемана, чтобы не отставать от конкурентов, разработка ПО должна продолжаться в течение всей жизни продукта.
Если проект имеет выручку, конкуренты есть всегда. Когда бизнес будет расти, появятся управленческие и операционные процессы, архитектурные задачи, бизнес-анализ, юридические, бухгалтерские, финансовые вопросы, связи с общественностью, корпоративные правила.
Что, если нанять программистов, которые будут писать код без планов, тестов, трекеров, а просто будут созваниваться и обсуждать по ходу дела? Может быть, разработчики правильно поймут задачу и напишут правильное решение, а может быть, придется несколько раз сменить специалистов и несколько раз переписать приложение. Разница в предсказуемости результата.
