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

— Ваш дом в аварийном состоянии, требуется реконструкция, - сказал прораб. — Мы протянем силовой кабель, чтобы запитать оборудование, выроем котлован, сделаем водоотведение, зальем фундамент…— Нет, нет! — прервал его владелец дома, — мне не нужен котлован, мне нужны стены! Дом!— В таком случае, может быть, Вы подумаете о покупке модульного дома? — предложил прораб. 

В прошлом месяце я общался со стартапом. У него есть работающий веб-сервис, который разные люди писали несколько лет, и теперь руководство думает что с ним делать. Основатели рассказали мне о своем желании нанять команду из десятка разработчиков, чтобы переписать или модернизировать приложение. Я спросил их про user story, документацию, трекер задач, и они ответили, что этого у них нет. Они попросили составить список того, что я предлагаю им сделать, и я написал вот это:

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

2. Определить контексты по DDD и создать высокоуровневую документацию, чтобы обсуждать архитектуру и помочь новым разработчикам осваиваться в проекте.

3. Определить узкие места системы, которые вызывают проблемы с масштабированием и доступностью.

4. Согласовать среднесрочные цели IT-команды с высшим руководством.

5. Создать рабочий процесс на инструментах командного взаимодействия - таких, как доска, трекер, мессенджер, репозиторий.

6. Организовать процесс найма и вхождения в проект новых разработчиков.

7. Наладить системы мониторинга и бекапа.

8. Сделать декомпозицию среднесрочных задач по этапам и написать календарный план.

9. Сделать CI/CD.

10. Написать план изменения архитектуры.

11. Выставлять приоритеты задачам в беклоге.

12. Наладить регулярные встречи IT-команды с продактом и отчеты высшему руководству.

А где разработка? Ответ - весь список. Все это входит в «Жизненный цикл ПО". 

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

Все перечисленное связано с деньгами.

1. Ключевые параметры, которые влияют на продажи: трафик, конверсия, возвраты, сколько клиентов возвращается, сколько уходит, и так далее. Мы все любим исследования, обсуждать культуру разработки, спорим из-за стандартов, но оценка IT-компаний - это произведение годовой выручки или размера клиентской базы на мультипликатор, и код не принимается во внимание вообще. Задачи разработки должны быть привязаны к важным измеримым параметрам бизнеса. Я принимал участие в разработке множества проектов, и помню несколько случаев, когда владельцы-управляющие растущих проектов игнорировали серьезные изменения ключевых параметров. Один проект терял трафик из-за конкурентов, у другого выросли возвраты денег за оплаченные покупки. Игнорирование этих проблем разрушило проекты всего за несколько месяцев после многих лет работы. Несмотря на то, что технически эти проекты надежны, и до сих пор приносят небольшие деньги, доля рынка потеряна навсегда. Обратную ситуацию я помню в корпорации Oracle. Каждому сотруднику: разработчику, тестировщику, менеджеру — рассказывали о том, сколько миллионов долларов выручки у продукта, над которым они работают, какая рыночная доля, сколько клиентов пришло, сколько осталось, кто конкуренты, и так далее. Были общие собрания, на которые приезжали вице-президенты, и делали для коллектива тот же доклад по результатам, который они делали перед советом директоров. Как можно видеть по отчетам Oracle corp, такая концентрация на результатах работает очень хорошо.

2. Бизнес-логика - хороший критерий разделения системы на модули и сервисы. Определение контекстов помогает людям понимать друг друга, уменьшить потери времени в общении и определить зоны ответственности. Кроме того, изучение логики приложения - часть процесса найма новых сотрудников. Инвестиции в высокоуровневую документацию окупаются с каждым новым сотрудником, модулем системы и сервисом.

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

4. Среднесрочные цели - это то, за что компания платит сотрудникам IT-подразделения. Писать планы - не критично для выживания компании, но их отсутствие обычно означает, что разработчики только играют в исследования и спорят о стандартах, но мало времени уделяют тем задачам, которые могут повлиять на бизнес.

5. Процесс разработки с доской, трекером задач, системами контроля версий, совещаниями, проектированием, code review, сборкой, тестированием и выкладкой - естественный для большинства команд. Мы просто не можем предсказуемо и постоянно выкладывать в работу задачи и соблюдать SLA - процент времени доступности системы, без надежных процессов разработки.

6. О найме. Почти все в проектах делают наемные сотрудники. Нужно ли делать найм процессом, или руководство нанимает людей на нерегулярных интервью, зависит от планов роста бизнеса. Проверка гипотез и масштабирование требует разных специалистов. Активно растущим стартапам нужен процесс с минимальным участием высшего руководства.Стоимость адаптации - это сумма зарплат сотрудников, которые обучают, плюс недополученная прибыль от задач, которые не выполняют сотрудники во время обучения новых сотрудников. Крупные корпорации могут позволить себе несколько месяцев на вхождение нового сотрудника в проект. Однако, большинству проектов нужно, чтобы сотрудник начинал выполнять задачи как можно быстрее.Относятся ли в компании к найму как к процессу, или это разовые события - простой показатель планов компании расти.

7. Мониторинг систем, протоколирование, планы резервного копирования и восстановления - не первоочередные задачи, которые нужно выполнять при запуске MVP. Это становится выгодно, когда проект начинает тратить деньги на привлечение клиентов. Все однажды ломается, и чем больше бюджет, тем важнее становится способность системы обслуживать поток денег непрерывно. Резервные копии данных - это не управленческое решение, это естественный способ сократить простои. 

8. Декомпозиция среднесрочных планов по этапам и эпикам нужна чтобы сделать разработку предсказуемой, быстрее узнавать о проблемах, и решать их. Это нужно чтобы сокращать простои сотрудников из-за проблем, которые от них не зависят.

9. Выгода от непрерывной разработки и непрерывной доставки (CI/CD) не очевидна. По закону Лемана, сложность программного обеспечения растет вместе с развитием системы, если не принимаются меры по сдерживанию роста сложности. CI/CD - это усилия команды разработчиков по сдерживанию роста сложности. Покрывая код тестами и запуская их на стендовых серверах при сборках, мы сдерживаем рост затрат на разработку. Эта задача находится внизу списка потому что она оправдана только для растущих и успешных проектов. Для большинства обычных проектов достаточно выкладки из релизной ветки git. Если растем без CI/CD - тоже ничего страшного, однако, нужна команда QA такого же размера, как команда разработчиков, удваивается площадь офисов, количество техники и менеджеров на совещаниях. Проект будет медленнее расти, но на растущем рынке можно не замечать этого годами. Я знаю несколько крупных проектов без тестов, в каждом тратят сотни тысяч долларов в год на переписывание тех частей кода, которые не были покрыты тестами. 

10. План изменения архитектуры - это одна из самых важных задач из тех, которые позволяют ускорить разработку функционала, который может серьезно повлиять на бизнес и масштабировать успешную модель. Этот план позволяет расставлять задачам верные приоритеты. Я ставлю эту задачу в конец списка потому что она не критична. Этот план не нужен для поддержания работоспособности системы. Он нужен нам, когда у нас есть амбициозные цели на серьезный рост и соответствующие ресурсы. Это не управленческая задача, это задача сотрудника на позиции архитектора.

11. Выставлять приоритеты задачам в беклоге можно по-разному, нет единого правила для всех. В методологии SCRUM приоритеты выставляет команда на planning-совещаниях. В традиционных моделях приоритеты выставляет руководитель команды. У руководителя-чайки нерегулярность изменения приоритетов приводит к отсутствию приоритетов вообще. Людям удобнее работать, когда они знают правила определения приоритета задач. Когда правила известны, люди учатся выполнять более важные задачи, чтобы чувствовать себя важными.

12. Регулярные встречи с руководством, отчеты лицам, которые принимают решения, и внимание позволяют людям чувствовать, что они правильно поступают, ощущать себя частью чего-то большего. Это помогает команде пережить кризисы.

Итак, сколько времени займет сделать веб-сервис? Чаще всего, ответ будет "Возьмите Wordpress, как поступили 38% веб-сайтов в интернет». Зачастую задачу можно решить без команды программистов. Можно использовать SAAS, взять коробочное решение или отдать задачу на outsource. Конечно, если вы не строите бизнес в IT. По законам Лемана, чтобы не отставать от конкурентов, разработка ПО должна продолжаться в течение всей жизни продукта. Когда бизнес будет расти, появятся управленческие и операционные процессы, архитектурные задачи, бизнес-анализ, юридические, бухгалтерские, финансовые процессы, связи с общественностью, корпоративные правила.

Что если просто писать код без планов, тестов, трекеров - просто созваниваться и обсуждать по ходу дела? Может быть, разработчики правильно поймут задачу и напишут правильное решение, а может быть, придется несколько раз сменить разработчиков, и несколько раз переписать приложение. Разница в предсказуемости результата.