Есть широко известный мем - один мужик копает а десяток стоят по краю ямы и смотрят. Обычно он сопровождается подписями - например, копает Месси и смотрят 10 других игроков сборной Аргентины. Но, пожалуй, самый распространенный вариант - это копающий разработчик, а над ним “скрам-менеджер, продакт оунер, менеджер проекта, командный менеджер, релиз-менеджер, айти-директор и т.д.”:
И такая ситуация кажется мне действительно похожей на реальность. Сразу оговорюсь - далеко не все менеджеры это бесполезное и наблюдающее за процессом звено - мне встречались толковые продактоунеры - способные разобраться со сложной логикой и выдать ясные и четкие требования. Но общая тенденция такова что менеджер просто является “посредником” между высшим руководством и разработчиками. У этого есть несколько причин. Во-первых, потому что именно разработчик а не менеджер очень часто оказывается тем кто знает и понимает все детали процесса - вот ему и поручают написать документацию (он же писал приложение - он и знает его лучше всех) и поговорить с заказчиком - понять что надо доработать (так как только программист понимает все тонкости бизнес-логики). Во-вторых - и это уже сугубо российская черта - у нас культура менеджерства на не особо развита. В западных компаниях (по крайней мере по моему опыту) менеджер это по сути такой же работник со своим четким кругом задач и обязанностей - и ему в голову не придет перекладывать разработку ТЗ или его согласование на разработчиков. В наших же реалиях менеджеры позиционируются как “начальники” цель которых - заставить работать других - и чем больше тем лучше. И вот на поприще “выжать из разработчика максимум” менеджеры очень даже преуспели - легко навешивания на разработчиков дополнительные задачи и “завиновачивая”. При том что разработчики - чаще всего привыкли к реальной работе а не подковерным разборкам и пикированием на совещаниях - в итоге остаются виноватыми и нерадивыми. Попытаюсь описать как это чаще всего происходит - чтобы юные айтишники понимали с чем столкнуться и продумали как этого можно избежать.
Новые требования
Ставится простая задача, разработчик называет сроки - в итоге “выясняется” что надо далеко не это - а пересмотр сроков уже не возможен, ибо Кабан Кабаныч ждут-с. Так, была задачка - прилетает xml-ка, ее пропарсить и сохранять в БД, говорю день работы. Выясняется что xml-ка может прилетать в нескольких версиях, и всех данных в ней нет - надо стучаться в другой сервис, а он отвечает не сразу а асинхронно - то есть в реале работы уже на 3-4 дня… Лечится только требованием четко прописанных требований.
Испорченный телефон
Разработчик говорит менеджеру что к концу недели продемонстрирует прототип приложения - менеджер докладывает айти директору что на неделе запускаем в тестовую эксплуатацию, айти директор докладывает Кабанычу что практически все готово, ставим на прод послезавтра. Лечится написанием подробных писем - что именно команда сделает и покажет к пятнице.
Продакшен драйвен девелопмент
Еще один вариант с нечеткими требованиями - когда приложение пишется - и только на этапе тестирования возникают правки без которых его нельзя запускать. При этом, поскольку запускать нельзя - то считается что это программисты не то сделали. Лечится опять же через требования четкого ТЗ с самого начала разработки.
А потом скорректируем…
Изначально выставляются оптимистичные сроки - на все замечания идет “если будут сложности - конечно, всегда скорректируем”. Реальность такова что увеличивать сроки никто просто так не даст - а если все же придется - то разработчиков обвинят в лени и нерадении. Лечится только через постоянное проговаривание - считаем сроки нереальными.
На все руки…
И еще один вариант расширения требований в процессе. Ставится задача по разработке сервиса. Но в ходе внедрения выясняется, что надо предусмотреть авторазваетывание, работу в кластере, мониторинг, бэкап БД и т.д. И, собственно, разработка сервиса - это едва ли не половина от того что от вас ждут. Лечится - как всегда - четким ТЗ - что и за какон время делают разработчики.
Параллельная разработка
В ходе работы возникает “срочная” задача - исправить баг на проде, помочь другой команде в дедлайне… Вы беретесь за нее - “по умолчанию” уверенные что сроки основной задачи сдвигаются. Но - не тут то было - менеджер делает удивленное лицо и говорит, что отвлечение на другие задачки - это никак не повод срывать сроки… Лечится - через проговаривание сроков. Переключаемся на другую таску? Без проблем, добавляем три дня (с запасом, так как переключение тоже требует времени).
Кабан Кабаныч уже спрашивал…
У менеджеров патологическая боязнь Кабаныча. Если он спрашивает про какой-то проект - будет ли он сделан в этом месяце - даже если сроки стояли в конце квартала - менеджеры зачастую блеют что да, будет. А потом бегут к разрабам “Кабан Кабанычу очень важно, он тут встречался с Михаил Владимировичем и Сергей Семеновичем, и обещал им… так что нам надо постараться, сделать любой ценой… ” Лечится тем что не надо бояться и поддаваться на давление. “Умрем но не подведем” - точно неверная позиция. Это не вы накосячили придумав нереальные сроки. И не вы, скажем откровенно, получите основные плюшки если все сделаете вовремя. Не обязательно утверждать что ничего не сделаем, нет. Можно предложить варианты - сделаем но без дизайна. Или - сделаем но дайте еще 3х разрабов (хотя не, не дадут…) или, если сами готовы - сделаем но за работу на выходные - двойной оклад (или двойные отгулы, решать вам).
Не бойтесь отстаивать свою позицию, не бойтесь что за “непослушание” вас уволят (а если и уволят - зачем работать там где на вас воду возили…) - как бы не “просел” рынок - разработчики с опытом и умеющие доводить до релиза проекты - были и будут в цене - куда большей чем прослойка менеджеров.
Комментарии (48)