Ув.тов.Asfikon у себя в блоге затронул интересную тему: Десять веских причин не тащить в продакшн новые игрушки. Действительно, если бездумно тянуть в проект с 10-летней историей и огромной кодовой базой что-то совсем недавно появившееся на свет, то хорошо это вряд ли закончится. Но, с другой стороны, прогресс не стоит на месте, свежие веяния нужно ловить и направлять в нужное русло. Поскольку то, что позавчера казалось почти невозможным, вчера делалось с кучей приседаний, а сегодня это уже в новой версии стандартной библиотеки.
Посему, вопрос в том, как же оптимальным образом совместить развитие приносящего деньги продукта, эксперименты с которым чреваты самыми тяжелыми последствиями, с освоением новинок и подготовкой их использования в продакшен коде.
Хорошим ответом на этот вопрос могут стать "подпольные проекты".
Подпольный проект -- это проект, о котором, начиная с некоторого иерархического уровня, никто не знает. Как правило, в проект вовлечено очень мало людей. Зачастую проект выполняется с ведома руководителей самого низкого уровня -- тимлида или начальника отдела. Иногда даже они могут не знать про подпольный проект.
Насколько я могу судить, подпольные проекты в подавляющем большинстве случаев являются личной инициативой их исполнителей. Т.е. у кого-то возникла идея и он приступил к ее воплощению. По ходу дела к нему присоединяются сторонники и помощники. А может и не присоединяются. Тут уж как пойдет.
Сам проект может принести какой-то ощутимый результат, а может и не принести. Тут так же как пойдет. Заранее не предскажешь. Этим, кстати, подпольные проекты отличаются от официальных: провал официального проекта никого не обрадует, особенно если этот проект заказной. Тогда как неудачное завершение подпольного проекта -- это нормально. Не получилось? Да и фиг с ним, особо никто ничего не ждал. Хотя положительные последствия могут быть даже в случае полного провала.
Ну, например, у вас в команде мог быть юноша бледный со взором горящим, который очень хотел помахать шашкой, бил себя пяткой в грудь и утверждал, что с помощью вот этого новейшего супер-пупер велосипеда со сложной формой колес он в одиночку за неделю все сделает. Вы дали ему такой шанс в виде подпольного проекта. Он проколупался месяц, устал следить за сложной формой новых колес, стал трезво оценивать свои силы и перестал смотреть на вас как на впавшего в старческий маразм старпера. В итоге вы заимели в команде нормального разработчика. Дорогая это цена за усиление вашей команды?
Или же, работая над подпольным проектом вам пришлось настолько глубоко погрузиться в вопросы оптимизации производительности БД, что вы разобрались, как можно ускорить ваш основной проект, даже не используя каких-то новых инструментов и не переписывая всю работу с БД заново.
Тут как в эволюции -- происходит почти случайное формирование чего-то нового или не очень нового. Что тут же проходит жесткую проверку на жизнеспособность. И либо выживает, либо нет. Либо дает толчок к поиску в другом направлении. В любом случае вы получаете информацию о том, куда имеет смысл двигаться, а куда не имеет. Что, на самом-то деле, очень дорого стоит.
Но почему такие поиски должны быть подпольными?
Причины разные.
Начать с того, что любое начальство чуть выше тимлида всегда озабочено тем, как обеспечить один или несколько важных проектов ресурсами. Причем чем выше начальство, тем больше озабочено. Поэтому если вы придете к руководству с предложением потратить неделю-месяц-полгода работой над чем-то, что может принести, а может не принести какой-то эфемерный результат в будущем, когда людей не хватает, чтобы затыкать текущие пробоины в едва держащемся на плаву главном проекте... Это значит, по меньшей мере, признаться в том, что люди у вас не загружены, у них от безделья дурные мысли в голове. Посему нужно их срочно спасать большими дозами трудотерапии.
Очень серьезно официальный статус меняет отношение к проекту у исполнителей. Просто на уровне психологии и внутренней мотивации. Одно дело, когда проект является твоей собственной проверкой на... На что угодно. На прочность. На способность что-то придумать. На способность довести до ума. На способность кому-то что-то доказать. Когда ты работаешь не за страх, а за совесть. Да даже тот факт, что ты никому ничего не должен и можешь бросить все, когда станет совсем уж невмоготу -- даже это может держать подпольный проект на плаву. И совсем другое дело, когда тебя обязали это делать. Есть задача, есть сроки. Давай, работай на результат. И пофиг, что тебя двигало раньше.
Официальный статус проекта так же сопровождается появлением целой кучи бюрократии и новых людей, которые имеют право следить за ходом проекта, да не просто следить, а вмешиваться. Причем это не только их право, но еще и обязанность. При работе над экспериментальным проектом есть большая разница, делается ли какая-то фича потому, что разработчику она кажется важной, или потому, что это указание менеджера. И за ход работы над которой нужно отчитаться.
Не знаю, как у кого, но лично у меня был довольно четкий водораздел: либо мне отдается задача целиком и я отвечаю за поиск решения и его воплощение в жизнь, либо же мне говорят что, как и когда делать. Тут все просто: если нужно что-то придумать, то дайте возможность придумать. А возможность придумывать -- это, прежде всего, отсутствие задалбывания, т.е. высокая степень свободы. Если нужно выдумывать, но свободы нет, то потрудитесь тогда выдумать решение сами, а мне предоставьте конкретную последовательность четких задач: сделать это, затем это, затем вот это.
Как раз подпольный проект дает такую степень свободы. Официальный -- нет.
Что нужно для того, чтобы подпольные проекты могли существовать? Отсутствие тотальной прозрачности процессов. Ограниченный контроль. Реально воплощенный в жизнь принцип "don't ask, don't tell" -- когда вы предоставляете возможность подчиненным не врать вам, они не будут этого делать. Более того, понимая, что степень доверия к ним зависит только от них самих, они сами будут заинтересованы в том, чтобы максимально полно держать вас в курсе происходящего.
Как при этом держать ход проектов под контролем? Например, при помощи контрольных точек. Поверьте, можно вести проект, при этом не сжимая его команду тисками тотальной отчетности. Об этом говорят даже те, кто в свое время приложил массу усилий для внедрения метрик проектов. Правда, управление при этом будет в большей степени искусством, а не ремеслом. Что чревато, если у вас нет способностей и желания учиться...
Но вернемся к первоначальной теме. Если у вас есть возможность вести подпольные проекты и вы научились при этом успешно запускать официальные, то вы можете пробовать новое. Не важно, что именно: язык программирования, фреймворк, СУБД, ОС или же иную схему организации работы команды. У вас появляется собственный полигон для обкатки нового. Базируясь на результатах с этого полигона вы сможете более адекватно оценивать, можно ли запускать что-то в продакшен или нет.
А вот когда такого полигона нет, когда тотальный учет и контроль убил подпольные проекты и здоровую инициативу снизу на корню... Тогда да. Тогда запуск какой-нибудь MongoDB в нагруженном проекте будет сродни прыжку без запасного парашюта: скорее всего, все будет нормально, не дураки же решение принимали. Но второй попытки просто не будет :)
Комментариев нет:
Отправить комментарий