Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Почему разработка программного обеспечения тесно связана с бизнесом и деньгами

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

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

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

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

— Нет, нет! — прервал его владелец дома, — мне не нужен котлован, мне нужны стены! Дом!

— В таком случае, может, вы подумаете о покупке модульного дома? — предложил прораб.

Иллюстрация Уляны Патоки

Наше время

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

  1. Перечислить ключевые параметры, которые влияют на продажи: SLA, функционал — что угодно, чтобы привязать виртуальные задачи к реальному миру.
  2. Определить контексты по DDD и создать высокоуровневую документацию, чтобы обсуждать архитектуру и помочь новым разработчикам осваиваться в проекте.
  3. Определить узкие места системы, которые вызывают проблемы с масштабированием и доступностью.
  4. Согласовать среднесрочные цели IT-команды с высшим руководством.
  5. Создать рабочий процесс на инструментах командного взаимодействия таких, как доска, трекер, мессенджер, репозиторий.
  6. Организовать процесс найма и вхождения в проект новых разработчиков.
  7. Наладить системы мониторинга и бэкапа.
  8. Декомпозировать среднесрочные задачи по этапам и написать календарный план.
  9. Сделать CI/CD.
  10. Написать план изменения архитектуры.
  11. Выставлять приоритеты задачам в бэклог.
  12. Наладить регулярные встречи 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. По законам Лемана, чтобы не отставать от конкурентов, разработка ПО должна продолжаться в течение всей жизни продукта.

Если проект имеет выручку, конкуренты есть всегда. Когда бизнес будет расти, появятся управленческие и операционные процессы, архитектурные задачи, бизнес-анализ, юридические, бухгалтерские, финансовые вопросы, связи с общественностью, корпоративные правила.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному10
LinkedIn

Схожі статті




18 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

а боль должна быть от того, что только один разработчик из ваших знакомых профессионал своего дела. Тесты это неотъемлемая часть работы программиста и это печально что наша индустрия находится в столь печальном состоянии, что мы до сих пор об этом говорим

Спасибо за статью, было приятно прочитать!

Ключевые параметры, которые влияют на продажи: ...

С чего бы начать)

Начнем с согласия — вообще неплохо бы в компании иметь консенсус относительно состояния дел, целей и средств их достижения, здесь нет разногласий, если не путать желаемое с действительным.
Сбор, анализ и проверка (sic!) данных о ключевых параметрах производятся да-а-алеко не в каждой компании.
Опять-же можно послушать истории Chamath Palihapitiya о том как вводилась культура работы с данными в Facebook — ему пришлось вступать в контролируемые конкурентные конфронтации со старожилами компании опиравшимися на свое субъективное мнение, лишать их репутации в глазах Цукеберга, получая все большие и большие части продукта под управление data-driven команды (и параллельно выстраивая инфраструктуру для сбора, анализа, проверки аналитических данных). Истории трансформаций компаний с плохой аналитикой в компании с хорошей — это достаточно редкое явление.

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

Ребята в Intel и Boeing тоже так думали, пока не потеряли кусок мультипликатора из-за технологической ошибки (в результате деградации технической культуры).

Задачи разработки должны быть привязаны к важным измеримым параметрам бизнеса.

Было бы здорово, но проблема в том, что определение к каким именно параметрам привязаться, а к каким не привязываться — не так просто определить (да и как именно привязаться?) — это управленческие решения. Для влияния на эти решения необходимо участие в процессах выбора целей и путей.

В общем — координация и политика.

Вот вам пример — переход Apple на собственные процессоры — вы же понимаете, что подобное решение возможно только в условиях существования подходящих инструментов — к решению этой задачи приступили приблизительно 15 лет тому назад (и все это время никакой связи с продажами/возвратами эта активность не имела). Такой маневр в принципе не доступен многим компаниям по простой причине — они не способны функционировать как организация в таких временных рамках. Apple уже меняла архитектуру процессоров в своих системах, и с логистикой и тонкостями такого маневра в организации знакомы. И в корне этого маневра — давнее техническое наблюдение о сравнительной энергоэффективности ARM-архитектуры.

Спасибо за большой комментарий по делу. Да, выбор ключевых параметров, измерение — это и есть управление. Гейтс тоже писал про выбор параметров и важность измерений в «Бизнес со скоростью мысли».
Что касается, Boeing ситуация немного иная — у них официальный девиз «Ставить компанию на кон каждые двадцать лет», в этот раз они сознательно попробовали отдать все на outsourcing — не получилось, и они это признали.

«Сбор, анализ и проверка (sic!) данных о ключевых параметрах производятся да-а-алеко не в каждой компании.»
Если мы не знаем как или не оцениваем свою эффективность, то ее будет оценивать кто-то другой. И скорее всего не так, как нам этого хочется.

Хорошо структурировано, спасибо!

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

— мне не нужен котлован, мне нужны стены! Дом!

Улучшение каких элементов Вам наиболее интересно?

Декомпозиция среднесрочных планов
План изменения архитектуры
Процесс разработки

Интересен execution опыт, в условиях когда не хватает людей, нельзя останавливать разработку, есть ожидания сверху и односторонняя коммуникация в стиле «бежим вот туда».

в условиях когда не хватает людей, нельзя останавливать разработку, есть ожидания сверху и односторонняя коммуникация в стиле «бежим вот туда».

ну, то есть на каждом реальном проекте

Односторонняя коммуникация — это молитва, по приказам надо докладывать о ходе исполнения и по результатам. Декомпозиция выполняется строго до уровня квалификации исполнителя, иначе будет или «чайка-менеджмент», или «микроменеджмент». Соответственно, для тимлида и сисадмина нужно делать разный уровень декомпозиции. Остальные темы достойны отдельных статей.

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

Когда уровень квалификации специалиста непонятен — это Уолли из комиксов про Дилберта! :) Если что-то нельзя оценить — это просто не часть бизнеса. Это может быть важная часть жизни, но с бизнесом это не связано.
Переезд в облако — это уровень компетенции CTO и SRA. CEO может поставить задачу CTO оценить требуемые ресурсы, ожидаемое изменение SDLC и SLA.
А планы и должны «ехать». Планы — это цель + критерий успеха с milestones. Регулярно измеряем. Не вписываемся — меняем или критерий оценки, или задачу, или исполнителей.

Отличная статья, правда резко оборвалась. По прочтению осталось чувство незавершённости)

Спасибо, я постараюсь это учитывать в будущих статьях. С концовкой есть одна загвоздка — happy end бывает только у инвесторов, а у разработки концовка всегда одна. Цель хороших процессов разработки — как у здорового образа жизни, отложить концовку как можно на дольше. Такая, вот, незадача. Даже не знаю что тут можно придумать. :)

Ви плутаєте функціоналність з функціоналом)))

так, обидва — не наукові терміни, але функціональні вимоги — надто довго

Шикарная статья.

Підписатись на коментарі