Эта публикация о том, как управленческие подходы в разработке ПО могут работать против бизнеса. История вымышленная, но все описанные ситуации – собирательный образ реальных случаев. Если вам покажется, что описанные события слишком узнаваемы – значит, это просто совпадение.
Глава 1: Любая система противится изменениям
Часто подходы к разработке ПО в компании приводят к потере прибыли, но далеко не всегда это приводит к разорению. Убыточные компании могут существовать годами, и никто не знает, исчезнут ли они или смогут протянуть дальше.
Руководство осознаёт проблему и пытается что-то изменить, но система сопротивляется. Например, вводится новая должность, на которую возлагают техническое руководство несколькими проектами. Нанимают человека, который приходит с идеями, но никто не готов делиться полномочиями.
Все процессы отлажены, всё работает – пусть даже убыточно.
Попытки изменений натыкаются на стандартные отговорки:
"Это не запланировано в текущем квартале."
"Задачи заказчика важнее, чем ваши."
"Мы не можем приступить к этой задаче, пока не выясним все требования."
"У нас нет ресурсов на эту задачу."
За каждой фразой стоит логичное объяснение, но в реальности и ресурсы есть, и время есть. Просто нет желания меняться.
Зарплата платится, работа идёт, а убытки? Это не проблема рядового сотрудника – есть спонсоры, которые всё спишут.
Как результат, новые должности не решают проблему, а лишь увеличивают финансовую нагрузку. Возникает порочный круг: попытка изменений делает только хуже, и желание что-то менять пропадает окончательно.
С одной стороны, всем очевидно, что нужно что-то менять. С другой – никакого стимула для перемен нет, пока финансирование продолжается.
Но без воли к изменениям ничего само не изменится.
Почему так происходит?
Курт Левин в своей работе "Frontiers in Group Dynamics" (1947), опубликованной в журнале Human Relations, описал основные причины сопротивления изменениям:
Индивидуальные факторы – привычки, страх перед неизвестным, потеря стабильности.
Групповые нормы – коллективное давление сохранять привычные методы работы.
Структурные барьеры – бюрократия, организационная инерция, жёсткие процессы.
Кроме того, Левин выделял причины, по которым системы сопротивляются переменам:
Неопределённость – риск и страх выхода из зоны комфорта.
Потеря контроля – изменения угрожают привычным процессам.
Социальные барьеры – страх потерять роль или статус.
Структурные ограничения – технические или регуляторные факторы.
Чтобы изменить систему, недостаточно просто дать распоряжение. Нужно убрать сопротивление – включая и личные страхи сотрудников.
Каждый человек внутри системы боится, что в новой реальности ему не найдётся места. Когда на кону личный доход, мало кто готов рисковать.
А теперь представьте, как реагирует управленческая вертикаль.
Руководители не хотят терять кресла – для них перемены опасны не меньше, чем для рядовых сотрудников. Система инстинктивно защищает себя, блокируя любые попытки изменений:
Снижение зарплат для новых сотрудников – чтобы сократить затраты.
Расширение компетенций старых сотрудников – без дополнительных расходов.
Отказ от подрядчиков – чтобы минимизировать внешние контракты.
Сокращения – чтобы продлить агонию компании ещё на несколько лет.
Но это не изменения, а адаптация.
Глобально ничего не меняется.
Что будет дальше?
Но бизнес убыточен, и рано или поздно эта система рухнет.
Иногда компания протягивает дольше, чем кажется возможным, но чаще всего источники финансирования заканчиваются. Тогда долги остаются, а компания – исчезает.
В итоге работу теряют все. И кто-то должен будет отвечать за убытки.
Без воли к изменениям ничего не изменится. Лучше инициировать перемены сейчас, чем надеяться, что "пронесёт" и всё рухнет уже без тебя.
Но даже если компания осознаёт проблему и решает меняться, это не всегда означает реальные перемены. Иногда изменения принимаются формально, но на деле всё остаётся по-старому. Новые методологии внедряются, но не работают так, как задумано. Процессы якобы трансформируются, но продолжают буксовать в бюрократии и привычках.
Предлагаю перейти к разбору более конкретных случаев, с которыми я сталкивался в своей практике. Представим, что я недавно нанятый менеджер, который пришел в такую компанию и стал там работать. Далее речь пойдет от первого лица.
Глава 2: Разработку по Scrum можно начать, имея только базовые требования
Погружаясь в процессы компании, я стал искать причину убытков. На мой взгляд одной из проблем был сам процесс реализации функционала, который требовал клиент.
Задачи от заказчика ставились сильно заранее, долго обсуждались, скрупулёзно выяснялись все требования, производилась оценка сроков, но реализация ставилась где-то в будущем, например, в следующем квартале или через полгода. При этом, в компании декларировалось Scrum методология, был Scrum мастер и формально все “ритуалы” Scrum соблюдались.
Далее ситуация развивалась не очень позитивно. Когда подходил срок приступать к задаче выяснялось, что начать её не получится, так как есть другие задачи, которые ещё не закончены в данный момент. В итоге реализация задачи начиналась позже и сроки сдвигались, либо разработчики переходили в авральный режим. Потом, когда задача выполнялась, её показывали заказчику и тот находил в ней кучу недоделок. Устранение этих недоделок могло занять столько же времени, что и реализация самой задачи. Но заказчик уже не платил за эти доработки. Таким образом компания теряла часть прибыли, либо уходила в минус, так как заработную плату платить надо всегда, даже если это доработки.
И это все при методологии Scrum. Она так популярна в ИТ из-за того, что позволяет начать разработку продукта, не дожидаясь всех требований к нему. А регулярная сверка результатов с заказчиком позволяет устранять все недостатки “на ходу”, даже если все требования при этом ещё не уточнены. Об этом написано Джеффом Сазерлендом в книге “Scrum. Революционный метод управления проектами”:
Scrum ориентирован на итеративный процесс, который позволяет постепенно прояснять требования в процессе работы. В отличие от традиционных подходов (например, Waterfall), где все требования должны быть чётко определены до начала работы, Scrum позволяет начать с базового набора требований и улучшать продукт по мере получения обратной связи и появления новых данных.
Джеф Сазерленд – это один из разработчиков методологии Scrum и один из авторов Agile Manifesto.
Так же, на мой взгляд, популярность этой методологии именно в ИТ заключается в том, что стоимость переделки отдельных частей программного продукта гораздо ниже, чем переделка какой-то детали автомобиля или дома. Отсюда, если на какой-то итерации было реализовано, то что не понравилось заказчику, это можно переделать в следующей итерации.
Когда гибкость превращается в бюрократию
Была ещё одна странность в компании. В некоторых спринтах разработчики могли быть недозагружены, но при этом они не могли взять новые задачи из Бэклога, так как они не соответствовали цели спринта. Да, цель спринта – это важно, но надо понимать, что гибкость и прозрачность — ключевые принципы Scrum, поэтому цель и задачи могут корректироваться для достижения ценности продукта. Если есть время, то надо брать задачи из Бэклога, так как это повышает скорость разработки, а любые простои никак не отражаются на зарплате сотрудников.
Гибкое планирование как ключевой принцип
Так же пару слов о планировании задач. Планирование в Scrum отличается от классического. В Scrum планирование гибкое и адаптивное. Команда не планирует весь проект сразу, а работает итерациями, пересматривая планы на каждом этапе.
В Scrum не меняется только долгосрочная стратегия, определяющая конечную цель продукта. Остальные планы могут корректироваться. Объем выполненных работ может меняться в зависимости от бюджета и от скорости выполнения.
Если команда не укладывается по срокам, то можно закончить на каком-то приемлемом варианте для заказчика. Пожертвовать чем-то менее важным в пользу основного функционала.
Один из плюсов методологии Scrum заключается в том, что в любое время разработку можно остановить, получив рабочий продукт, который может и не удовлетворять всем требованиям, но при этом будет выполнять основной функционал.
Так же нередки случаи, когда от продукта заказчик отказывался, с минимальными финансовыми затратами, поняв, что это не то что ему нужно или не может быть в данный момент реализовано именно так, как он хочет.
Тут важно то, что при Scrum, решение о том, стоит ли продолжать или надо остановиться можно принять практически на любом этапе разработки, в конце очередного спринта.
Глава 3: Команда разработки полностью автономна
Принцип автономности команды так же был нарушен. Все проекты были разбиты на группы. В моей группе было 3 проекта. И для такой группы проектов существовал руководитель группы проектов, тимлид группы проектов и архитектор группы проектов. Эта тройка прорабатывала требования от заказчика для одного из проектов, составляла архитектурное решение для поставленной задачи и передавала всю созданную ими документацию в проект на реализацию. Она брала не все задачи, а те что считала наиболее важными или задачи, которые затрагивали 2 и более проекта.
При этом в каждом проекте была команда, в которой так же присутствовали руководитель проекта, тимлид проекта, архитектор проекта, группа аналитиков, группа тестирования и группа разработки.
Управленческий хаос
Отсюда возникал вопрос, а чем занимаются архитекторы и аналитики, которые находятся в проектах? За них все решалось на уровне группы. Но на уровне группы нет разработчиков и тестеров, как учитывать их знания при формировании требований к решению задачи? Фактически описание того как решать задачу и в какие сроки решалось сверху, без учета текущей ситуации в проекте.
Отсюда конфликты между теми, кто исполняет задачу и теми, кто их ставит. Возникают ситуации, когда реализация поставленной задачи не может уложиться в отведенный ей срок. И как результат, срыв сроков и санкции со стороны заказчика. При этом в методологии Scrum прописаны принципы самоорганизации команд.
Вот что написано в Scrum Guide (официальное руководство по Scrum, авторы Кен Швабер и Джефф Сазерленд):
Самоорганизация команды: В Scrum команда разработки должна быть самоорганизующейся, что означает, что она самостоятельно решает, как лучше выполнить задачу и распределить работу. Команда не зависит от внешних источников для выполнения своих задач. Это помогает повысить мотивацию и эффективность.
Кросс-функциональные команды: В Scrum команда разработки состоит из кросс-функциональных специалистов, которые обладают всеми необходимыми навыками для завершения работы, включая разработку, тестирование, анализ требований и другие аспекты работы. Это позволяет команде работать без внешней помощи, так как все ключевые компетенции находятся внутри команды.
Роль Scrum Master: Scrum Master помогает устранить блокеры, но не является внешним источником работы для команды. В своей роли он способствует тому, чтобы команда могла работать максимально эффективно, не вмешиваясь непосредственно в процесс разработки.
Фактически у команд отбирается возможность решать самостоятельно как лучше выполнить задачу. Им директивно спускается инструкция, в которой написано - что делать и как делать. Но при этом ответственность за результат лежит непосредственно на команде, которая разрабатывает продукт. Даже если задача затрагивает более одного проекта, команды могут разделить задачу по проектам и проработать взаимодействие. На уровне группы проектов нужно согласовать предлагаемые решения от команд и устранить возможные нестыковки, если они возникнут или выделить дополнительные ресурсы, если они понадобятся. Под ресурсами тут понимаются не только дополнительные специалисты, но и различные аппаратные решения – дополнительные сервера, например, или программные решения, облегчающие решение задачи.
Где ломается контроль
Так же, в ситуации, когда инструкции спускаются сверху, ослабевает контроль за исполнением задачи. Кто будет проверять, действует ли команда по инструкции или нет и как это проверить? Программный код каждый день видит тимлид команды, но не тимлид группы. Языки разработки в каждом проекте могут отличаться и постоянно вникать в код 3-х проектов не так просто и требует времени. Вероятность упустить что-то в этом случае сильно возрастает. Плюс начинает работать испорченный телефон - команда может по-своему истолковать предлагаемую им инструкцию и сделать все иначе, чем планировалось.
Тут опять сказывается специфика разработки программных продуктов. Структура решения и реализация алгоритмов постоянно меняется в коде продукта и отследить этот процесс не так просто, в сравнении с похожими ситуациями, например, в автомобилестроении при сборке нового автомобиля. Код постоянно меняется и то что написано вчера может отличаться от того, как это выглядит сегодня.
Глава 4: Дейли – это не Планерка
Как и положено по Scrum в компании проводилось ежедневное Дейли. Но оно было немного странным. На этом дейли руководитель проектов каждому раздавал задачи и давал указания, что ему делать. Длилось оно в среднем минут 30, но это не было похоже на те Дейли в которых я участвовал ранее. Это было больше похоже на планерку, в которых я принимал участие, когда проходил практику на предприятии учась в университете. В тех Дейли, которым я привык мы просто отвечали на 3 вопроса:
Что я сделал вчера?
Что буду делать сегодня?
Есть ли блокеры?
И не было никаких указаний кому и что делать. Блокеры обсуждались отдельно вне Дейли.
Груминг без команды
Как выяснилось отличия были не только в Дейли. Груминг так же проходил странно. Он мог проводится с одним из разработчиков, который оценивал задачу, которую он должен будет делать в следующем спринте. Остальные разработчики не участвовали в таком Груминге. При этом в компании сетовали на то, что каждый разработчик погружен только в одну часть проекта и мало что знает о других его частях. С одной стороны, такой Груминг меньше отвлекает других разработчиков от своей работы, с другой у команды не было единого понимания того, что происходит в проекте. Это отличалось от тех Грумингов, в которых я принимал участие в других компаниях. Мы собирались всей командой и оценивали задачи все вместе. Это отнимало много времени, но в целом у команды было понимание того, что мы делаем и какие задачи нам предстоят.
Планирование задач превратилось в директиву
Планинг тоже проходил необычно. На нем руководитель проектов просто назначал каждому задачи на спринт. Причем список задач для каждого разработчика составлялся им заранее. Разработчик мог отказаться от какой-то задачи, обозначив причину, но это было редко. Все просто соглашались с этими списками, так как сами же до этого оценивали эти задачи на "индивидуальном" Груминге. В моей практике в других компаниях, на Планинге мы выбирали задачи на Спринт и каждый мог взять понравившуюся ему задачу прямо на митинге. Никаких списков заранее не составлялось. Возникало ощущение какого-то тотального контроля за действиями разработчиков.
Когда тестирование не приоритет
При этом культура кодирования была низкой. Юнит тесты были, но они были отключены и при сборке проекта их не прогоняли. Они были странными, их было много, но покрывали они менее 20% кода в проекте.
Анализатор кода типа SonarQube так же не работал, хотя был установлен. И те ошибки, которые он подсвечивал никто и не собирался исправлять. Чаще всего ссылались на нехватку времени.
Общий синтаксис в коде отсутствовал и каждый писал, как ему удобно.
Были так же интеграционные тесты, но их было очень мало и делал их один человек, который недавно пришел в команду. Складывалось ощущение, что он их делал, так как его нечем было занять.
Регрессивного тестирования всего проекта не проводилось и автотесты отсутствовали. Объясняли это дефицитом тестеров в компании.
У фронтенд части приложения юнит тесты отсутствовали полностью. На вопрос “Почему?”, мне сказали: “А зачем? Тестеры и так все проверят!”.
Комментариев в коде практически не было. Причем фразу “Хороший код сам себя документирует” я слышал не один раз.
Понятно, что это все работает и возможно, что без ошибок, но мне нравится цитата Кента Бека на этот счет:
“Я разработал JUnit не потому, что люблю тестирование. Я разработал JUnit, потому что ненавижу баги.”
Кто-то может сказать, что у разработчиков мало времени и им просто некогда это делать, но по моему опыту, если это не делать, то затраты на поддержку такого кода и приложения со временем будут возрастать. Получается, что, сэкономив сейчас этому будет уделяться гораздо больше времени потом. В худшем случае этот код просто перепишут заново, так как не смогут в нем разобраться.
Заключение
В этой статье рассмотрены распространённые проблемы:
Непонимание принципов Scrum.
Формальное следование методологиям без их реального применения.
Жёсткая вертикальная структура, мешающая самоорганизации команд.
Игнорирование тестирования и контроля качества кода.
Важно не просто внедрять методологии, но и понимать, как они должны работать. Только тогда они помогут достигать бизнес-целей, а не станут формальностью, мешающей работе.
Эта компания — это собирательный образ, в который я поместил ошибки и странности, с которыми я сталкивался в своей работе. Возможно, в виртуальном мире у такой компании есть шансы на успех, но в реальности подобные подходы ведут к потере эффективности и росту убытков.
