Реформы в IT-отделе. Манифест разработчика

Преамбула

Я разработчик в небольшой организации. Цель моей работы — делать людям хорошо. Я ускоряю их работу, добавляя тот или иной функционал к уже существующему продукту, моими клиентами являются сотрудники самой организации. Современный бизнес очень динамичен, каждый день появляются новые идеи и потребности, то есть мой план расписан на год вперед, и каждый месяц перестраивается под новые задачи.
 
Однако, на фоне, казалось бы, динамично растущего бизнеса (кол-во сотрудников увеличивается на 10-15 человек в год) отдел IT растет значительно медленнее. Основное требование к выполняемой работе: “Быстро!”, как следствие плохо масштабируемый код, подверженный плавающим ошибкам.
 
Сейчас наша компания переживает новый виток развития ПО (период 5 лет), постепенно мы отказываемся от старых разработок и переписываем то, что есть, придерживаясь объектной модели и паттернов, а заодно и переезжаем на новые сервера (новые железо + софт), но требования остались на прежнем уровне — все должно быть  сделано вчера.
 
В очередной раз при релизе кода работа сотрудников была парализована на пару часов, и ген. директор спросила: “Ребята, сколько это еще будет продолжаться?”, на что я ответил: “Когда завершится переезд”, а спустя сутки прислал более подробный ответ, описав то, что меня волнует в последнее время все больше и больше.
 
Зачем я это рассказываю? А затем, что моя история не уникальна. Кому-то эта статья даст пищу для размышлений, а то и подтолкнет к действиям. Кто-то поделится своим опытом, а кто-то в очередной раз порадуется, что у него в компании все намного лучше.

Проблемы IT-отдела

На данный момент все проблемы, возникающие в процессе переезда, связаны с плохой архитектурой, отсутствием систематизированного подхода к разработке (речь о самой методологии), а так же отсутствием должного тестирования продукта (проверить тыкаются ли нужные кнопочки – это уже заключительное тестирование, ему должны предшествовать автоматические и/или автоматизированные ^[1]  тесты ^[2]).
 
Встав на путь создания движка и объектной модели в целом, у нас появилась возможность  избежать выполнения накопившегося технического долга ^[3], однако, без внедрения современных методик (например ^[4] или вот ^[5]), я боюсь, что мы снова погрязнем в этом же через 5-7 лет. У компании, несомненно, далеко идущие планы, а текущие программные продукты это основные её инструменты.
 
Да, быть может через столько лет профиль и инструменты компании изменятся настолько, что проделанная работа станет неактуальной, но какова вероятность этого? MS Office’у(2003) больше 10 лет, а это такой же инструмент, как и тот продукт, что мы разрабатываем. Мне кажется, если ни чего не поменять – все повторится, и через несколько лет компания будет ходить по этим же граблям.
 
К сожалению, для внедрения практик, о которых я писал выше, потребуется больше временных ресурсов, т.е. больше разработчиков. Изменив процесс разработки, повысится его научная ценность, а как следствие — “интересность”. При нынешней обстановке на рынке IT-кадров соискатели выбирают один или несколько интересующих их факторов: Деньги, Интересные задачи, обстановка в коллективе (пруф ^[6] ниже)

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

Выводы

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

• Необходимо остановить прием заявок на доработку программы, но нельзя прекращать работу по исправлению ошибок (неверная реализация бизнес-логики, полная неработоспособность отдельных модулей или приложения в целом, в общем, все, что  останавливает процессы в компании);
• Необходимо изменить базовые функции таким образом, что бы они реализовали объектную модель соответствующую реальной жизни, позволяющую масштабировать приложение. В помощь шаблон MVC ^[7]. На этом этапе уже нужно начать разработку через тесты (TDD);
• Что бы изменения проходили постепенно, необходимо реализовать адаптер для стыковки старого интерфейса и модулей с новым движком. Это позволит добавлять функционал, не останавливая работу. В помощь шаблон Адаптер ^[8];
• Реализовав Фасад ^[9], мы сможем понизить порог вождения в проект, т.е. сформировав базис, мы можем развиваться не только качественно, но и количественно;
• Новые разработчики приходят под руководство более опытных, при этом основной обязанностью новоиспеченных тимлидов становится направление новичков в правильное русло, проектирование базовых, критически важных объектов, рефакторинг “узких” мест, ну и не забывать, конечно же, писать код;
• Далее собрав команду и войдя в русло можно начинать применять Агил методологию, практически без вреда для проекта (предвижу временные затраты на утряску организационных моментов).

Автор: Ascott

Источник ^[10]