Ты работай, а я проверю
Одним из моих долгосрочных проектов является сотрудничество с государственным учреждением, занимающимся управлением спортивными объектами. Когда-то построил там отдел информационных технологий, а потом, после переезда в другой город, остался на удаленке в должности программиста 1С. Надо сказать, что в последнее время государство пытается внедрять профессиональные стандарты для значимых должностей. Цель то как всегда логична, чтобы за государевы деньги не работали проходимцы без надлежащих навыков. И вот однажды мне попался такой документ для профессии программиста. Это монументальное полотно произвело на меня неизгладимое впечатление...
Подробно описывать не буду, чтобы не травмировать вашу психику. Приведу кратко самое удивительное...
- Младший программист, Техник-программист - Разработка и отладка программного кода.
- Программист - Проверка работоспособности и рефакторинг кода программного обеспечения.
- Старший программист, Инженер-программист - Интеграция программных модулей и компонент и проверка работоспособности выпусков программного продукта.
- Ведущий программист, Ведущий инженер-программист - Разработка требований и проектирование программного обеспечения.
А чё, так можно было что ли?!?!?!?!?! Можно было сказать, что я уже давно не младший, негоже мне писать, буду проверять. А еще, что я вообще ведущий и ничего не делать разрабатывать требования. Ну думаю, государство наше как обычно хотело как лучше...
Ан нет. Посмотрел тут на ютубчике ролик про разработку в больших компаниях. Предприятие всем известное, бэк-офис у них не на модных интернет-технологиях, а (сюрприз, сюрприз) на 1С. Но сейчас не об этом. У них есть простые разработчики, которые работают, есть архитекторы, которые проверяют (делают code review) и есть главный, который занимается всем чем угодно, кроме работы внедрением и настройкой различных систем контроля задач и версий. Казалось бы, зачем опытным сотрудникам тратить свое драгоценное время на поиск чужих ошибок, они бы прекрасно, быстро и эффективно, могли разрабатывать сами. А если разделить людей на независимые направления, то и не сильно нужны системы контроля версий. Но нет, современная мода заставляет строить сложную иерархическую структуру.
А как принято у других? Заходит такой опытный командир корабля и говорит второму пилоту: "Митька, ты давай-ка рули, причем не только сегодня, а всегда, а я буду тебя проверять, могу иногда вздремнуть, но если аварийная ситуация, ты меня обязательно разбуди". Или идет финал лиги чемпионов, лучший футболист сидит в запасе и внимательно смотрит, как играют другие и только когда стали проигрывать 0-3, выходит на замену. Или известный писатель нанимает литературных негров, они пишут, а он только проверяет, удалось ли им скопировать стиль. Но так же не бывает. Во всяком случае я на это надеюсь. Бывает заслуженный спортсмен не может выступать по возрасту, по здоровью и становится тренером. Но это переход на руководящую должность, а статья о взаимодействии внутри коллектива.
В общем виде нормальная организация работы строится по принципу:
А для программистов почему-то становится популярным такое:
Неопытный работает, опытный проверяет.
Сомнительный принцип "Не знаешь - гугли, если что, исправишь".
Что за хрень? Почему так повелось? Могу предположить, что дело в популярности американских стартапов, где каждый начавший дело на каком-то этапе неизбежно должен выполнять больше управленческих функций, передавая разработку новичкам. По-другому никак, надо быстро, а опытных людей не найти. В нормальных же компаниях с постепенным прогнозируемым развитием схема с проверкой опытными неопытных, по моему, малоэффективна и только раздувает штат и бюджеты. Гораздо лучше нанимать разработчиков высокого уровня и поручать им независимые направления. У них могут появляться помощники, но такие которые помогают, а не выполняют всю работу.
Так что-же делать если вы программист... А ничего. Для вашего саморазвития подойдет любая из представленных организационных схем. А если вы опытный, то вам очень легко найти работу в тех проектах, откуда выгнали большие раздутые команды за неэффективность. Прийти туда и постепенно построить все нормально. Возможно даже придется уничтожить все системы контроля версий плохого кода и шаг за шагом переделать его в хороший.