Как развиваются процессы. Часть 1. Хаотическая разработка

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

Типы отделов разработки

Существует огромное множество различных способов разрабатывать программное обеспечение. Тем не менее, для простоты я разделил все это многообразие на три типа:

• Хаотическая разработка
• Проектная разработка
• Сервисный подход

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

Ранняя хаотическая разработка

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

На этом этапе руководство компании подходит к созданию внутренних программных продуктов несистемно и эмпирически. При появлении потребностей у бизнеса (в стиле «Василий Николаевич хочет себе в отдел Систему для своих продажников») руководитель IT отдела или замдиректора по информационным технологиям (давайте его называть такого человека CIO для простоты) принимает решение о покупке готового решения либо о разработке с нуля.

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

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

На новом месте работы нового программиста знакомят с будущими пользователями лично и практически в тот же день он приступает к кодированию системы.

При появлении потребности в новом решении нанимается еще один или два человека (уже работающий в отделе программист занят!).

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

Я работал в такой компании много лет назад, будучи еще студентом. Моими заказчиками и пользователями в большинстве своем были женщины предпенсионного возраста. Я писал для них «на коленке» софт по инвестиционному анализу проектов - в основном в Excel, VBA и на Visual Basic. Они сидели в соседней комнате и в пять часов вечера мы собирались вместе пить чай. Относились они ко мне очень бережно, с любовью и уважением и всегда защищали от руководства, если мне нужно было уйти пораньше или я был занят дипломной работой. Мои товарищи-программисты сидели со мной в одной комнате, но я слабо представлял, чем они занимаются - у них были свои заказчики. Мы общались, конечно, но, скорее, на общие темы - просто трепались.

Давайте рассмотрим некоторые свойства такой организации разработки в хаотическом стиле:

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

Зоопарк технологий
На этот момент руководство редко настолько прозорливо, что ограничивает программистов в выборе языков программирования, платформ и так далее. Отбора при найме по знаниям платформ тоже чаще всего нет. Считается более важным понимать бизнес-домен, нежели программировать на некотором языке. Очень часто можно встретить в одном небольшом отделе, например, 1С, Perl, Java и .NET.

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

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

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

Четких требований нет
Требования к решениям четко не формулируются. Чаще всего фиксируются устно, на листочке бумаги и в электронной переписке.

1: Мне ТЗ нужно.
2: давай созвонимся, на пальцах объясню
1: По телефону пальцы не видно...
(bash.org.ru)

Нет конфигурационного управления
Системы версионного контроля (такие, как Subversion или Git) не используются, поскольку нет необходимости синхронизировать работу команд. Вам это наверняка покажется преувеличением, но я сам лично видел, как в при необходимости архивы с исходным кодом просто перекидывались по электронной почте.

Нет проектирования пользовательского интерфейса
Системы выглядят очень по-разному. В частности, никакого единого подхода по созданию пользовательского интерфейса нет. Соответственно, удобство (usability) конечного продукта, мягко говоря, совершенно не гарантировано.

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

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

Итог
Как вы видите, проще перечислить чего нет, чем что есть. Практически никаких (описанных в литературе) практик программисты не используют.

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

Выглядит это так: приходите вы такой умный из другой компании и говорите:
— Слушайте, а почему у вас нет копоративного Wiki? Это очень удобно! Мы в прошлой конторе очень активно использовали!"

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

Особой потребности со стороны руководства и интереса со стороны товарищей не наблюдается, их применение живет на голом энтузиазме и быстро умирает после ухода человека или снижения его энтузиазма.

При всех ее недостатках хаотическая схема (до какого-то момента) работает довольно хорошо. Заказчики довольны, программисты чувствуют себя нужными. Она начинает буксовать, когда задач по разработке становится больше и количество программистов растет.

Кризис хаотической разработки

Первый клубок проблем возникает, когда поток входящих задач начинает превышать возможности имеющихся программистов. Это происходит в жизни очень многих компаний. Бизнес идет в гору, подразделения растут, компания достигает уровня «Давай-Давай» по Адизесу и хватается за каждую возможность заработать деньги. Заказы на новые решения начинают сыпаться на отдел разработки как из ведра. Отдел просто физически не способен с ними справляться.

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

Перечислю несколько типовых проблем:

Срыв сроков

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

Разработчик в эпоху кризиса хаотической разработки

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

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

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

На вопрос разработчика «что тебе нужно» заказчик вываливает на него свое видение решения проблем. Это конкретная функциональность, например «сделай мне отчет». Естественно, заказчик не является профессионалом в проектировании систем и придуманные им решения в среднем низкого качества. После реализации выясняется, что это совсем не то, что ему нужно. Программисты редко спрашивают заказчика о проблеме, которую он пытается решить такой функциональностью. А ведь такой простой вопрос часто позволяет подсказать заказчику правильный способ решения - например «тебе не отчет нужен, а форма с редактированием».

В итоге качество требований низкое, они постоянно меняются. Впрочем, есть и объективные причины - изменения требований. Меняется бизнес заказчика и его представления о том, как достигать намеченных целей.

Все это приводит к разрастанию объема работ по каждому решению из-за постоянных переделок и новых задач. Это также приводит к срыву сроков.

Недостаточная производительность

Сами сроки реализации, даже обещанные, а не реальные, становятся катастрофически неприемлемыми. Бизнес-пользователи хотят решения получать быстро, в идеале «вчера». Объемы работ по реализации даже относительно несложных решений становятся все больше и больше: возрастает количество пользователей системы и возможных сценариев использования.

Старый подход «один проект – один человек» не позволяет эффективно увеличивать производительность. Можно добавить в помощь разработчику еще одного программиста. Пока он освоит бизнес-домен и разберется в кодовой базе, его успевают перевести в другой проект, поскольку приоритеты меняются еще быстрее.

Зоопарк технологий уменьшает возможности по концентрации программистов на одном проекте. Программиста на Java не так-то просто переключить на проект, разрабатываемый с использованием MS Access.

На некоторых ключевых участках работ образуются узкие места. Например, в отделе только один разработчик на MS Access. Он обслуживал всех финансистов. У них появляется новый финансовый продукт для рынка. Работы для программиста вдруг становится очень много и никто в компании не может ему помочь.

Весь старый код также необходимо поддерживать. На этом этапе никто не задумывается об автоматизации тестирования. Документации по старому коду тоже, конечно, нет. Соответственно, багов в старом коде много, и на поддержку старых продуктов уходит иногда до 50%-80% времени программиста.

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

Низкое качество

Проблемы с коммуникацией. Коммуникации между разработчиками очень мало. В итоге программисты постоянно решают проблемы и задачи, которые до них уже были решены другими сотрудниками. Например, в одной компании я как-то насчитал 5 (пять!) систем управления оргструктурой для пяти разных отделов, решенную на трех различных языках программирования!

Количество багов. Размеры систем растут постоянно. Багов становится все больше и больше. Причем если размер системы растет линейно во времени, то «багоемкость» растет гораздо быстрее: помимо багов в новой функциональности появляются баги из-за связей новой функциональности с уже существующей.

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

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

Наведенные дефекты. Из-за низкого качества кода и дизайна исправление одних багов порождает новые баги. Бывает, что исправление одного бага привносит несколько новых! Тогда ничего не остается, кроме как бросить старую систему и с нуля рядом строить новую.

Спагетти-код. Код становится трудно читать. Системы хорошо знают только авторы. В итоге передать системы другим программистам практически нереально.

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

Отсутствие документации. Программисты не заинтересованы в документировании своей работы, да и времени на это никогда нет. Если старый программист уходит, новый остается один на один с огромной запутанной кодовой базой, в которой иногда практически нереально разобраться. Будучи программистом, я как-то переписывал систему, старая версия которой содержала 800 таблиц MS Access и примерно столько же модулей VBA с похожими именами. Когда у предыдущего программиста появлялись новые пользователи, он просто копировал старые таблички и модули и подправлял их.

Взаимодействие с заказчиком

Из-за всех перечисленных причин недовольство заказчиков растет. Называемые разработчиками сроки их не удовлетворяют, к тому даже эти сроки постоянно срываются. Качество результата низкое - работа отделов иногда даже останавливается из-за багов на production. Теперь такая проблема не так безболезненна, как раньше: компания выросла и остановка работы отдела из десятков и сотен людей приводит к серьезным последствиям.

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

Среди заказчиков-старожилов ходят легенды о программистах прошлого, которые «такую программу сделали бы за два дня».

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

Продолжение здесь :-)

Tags: