Как я провёл лето

Этот текст я пишу для того, чтобы подготовиться к отчёту о новом эксперименте, который поставили у нас на фирме и в котором я служу подопытным кроликом.

Как-то у нас на работе попробовали решить некоторое подможество проблем хитрым приёмом. Это подмножество включало в себя:

• Новые проекты, которое берёт фирма, зачастую гибнут вследствие неправильного общения с заказчиком, расстановки приоритетов, медленного первого релиза, неверных проектных решений...
• Фирма распадается на мелкие фракции, диффузия информации и знаний между которыми стремится к нулю.
• Сложно оценить уровень людей, работающих в глубоком одиночестве.
• Исполнители, уровень которых позволяет решать 80% повседневных задач вполне могут надолго затупить или начать неправильными костылями решать задачи из остальных 20%
• Старшим разработчикам, так называемым сеньорам (seniors) в этом же ворохе повседневных задач скучно и неинтересно, они тупеют и не могут поднять головы от сохи и посмотреть на звёзды.
• Наверно и ещё что-то.

Для всего этого вороха проблем директор предложил такое решение: вывести сеньоров из-под текущего проекта, дать им под крыло несколько проектов на правах "блуждающего форварда" - самим определять себе точку приложения усилий. Такой сеньор может и научить разработчиков техпроцессу, как делать продукт, как вести коммуникацию. Поучит, как писать код, как управлять репозиторием и трекером. Будучи свободен от оценок и обязательств, может выбрать себе интересную задачу и со вкусом её сделать без оглядки на заказчика - большой рефакторинг или ещё что-нибудь интересное. Он же поможет исполнителям повышать свою квалификацию, он же даст оценку этой квалификации при принятии решения о повышении. Он же поможет решить задачу из верхних 20%. И сможет распространять своё понимание хорошего на несколько проектов, что создаст конвекционное течение знаний, навыков и практик.

Есть одно опасение - а не задолбётся ли такой сеньор переключать контексты? Ну, это уж как он время своё организует.

Для оценки эффективности идеи выбрали тестового сеньора - меня. Посмотреть, что из этого получится. Так я и стал Муравьём Красная Точка. Этот текст о моих приключениях и промежуточном подведении результатов эксперимента.

В среднем, после пары замен, я вёл то три, то четыре проекта. Все, кроме одного - новые, ещё не имеющие стейджинг-сервера, не вышедшие в продакшн и не имеющие пользователей. Один - тот из которого меня вывели - давно запущенный проект с реальными пользователями, которые даже платят.

На одном из еженедельных совещаний руководства фирмы и её топ-сотрудников программист Стропалов Дима высказал мысль - а как оценивать результаты и полезность таких вот "свободных сеньоров"? Первое, и пока единственное, что пришло в голову - успех проекта и рост квалификации его исполнителей. Скорее всего, именно это и стало моим камнем преткновения на этом поприще. Конечно же, не то, что Дима высказал эту мысль, а сама мысль - у меня она появилась раньше.

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

Для меня важно получать зарплату не просто так и верифицировать результаты своей деятельности. Единственные критерии, которые я вижу - это рост квалификации исполнителей и успех проектов. С этого места всё меняется.

Как только я начинаю болеть за проекты, я перестаю быть свободным. От сроков и обязательств, от заказчиков и пользователей. Когда цель - это успех проекта, самостоятельное программирование становится роскошью и неверной тратой времени и сил. Время начинает полностью уходить на типичные менеджерские задачи - поддержка коммуникации, расстановка приоритетов и дорожных столбов, определение точек входа и выхода дополнительных специалистов, - дизайнеров, верстальщиков, - вразумление заказчиков и программистов, планирование релизов, поддержание порядка на Трекере. Если эти задачи решены - code review. Больше времени не хватает ни на что.

• Редактор кода на прошлой неделе я запускал один раз. В три часа дня. В пять я его закрыл. Нормальная ситуация.
• Приходится очень много писать писем, очень много разговаривать в живую и по Скайпу, очень много чатиться, очень много времени проводить на Трекере.
• Я стал гораздо больше переживать по поводу своих неправильных решений. Я очень сильно переживаю по поводу каждой из своих менеджерских ошибок, допущенных в этом качестве. 
• Я стал намного сильнее уставать. Да-да.
• Я вовсе не стал более свободным.

Не всё так мрачно. Мне нравилось то, что я делаю, когда я был программистом. Мне нравится то, что я делаю сейчас, когда я менеджер. В конце концов, это вполне логичный этап эволюции и профессионального роста на моём поприще. Да, по программированию скучаю, отсюда всякие разминки и прочее. Но разработка продукта - тоже интересная штука.

В какой ситуации я мог бы попрограммировать? Ответ очевиден - если на всех моих проектах всё хорошо. В частности, все уже в продакшене, у всех есть пользователи, у всех порядок на трекере и виден план их дальнейшего развития.

Вторым вариантом являлось бы наличие на этих проектах менеджера. То есть, было кому делать это работу. Тогда при сохранении критерия "с проектом всё хорошо - значит и сеньор справляется", сеньор мог бы позволить себе роскошь программирования.

Третьим вариантом может быть снижение количества поддерживаемых проектов до, скажем, двух. Теоретически управленческих задач тупо станет меньше, во столько же раз уменьшится количество отвлекающих запросов, и станет настолько легче, что по отношению к двум проектам можно будет исполнять все цели - и управление, и техническую помощь, и, собственно, произвольный вклад программированием.

Возможно, это всё мои комплексы. Возможно, мне стоит забить на эту менеджерскую возню и начать развлекаться с кодом проектов, заодно помогая их исполнителям советами и техническими решениями. Меня останавливает то, что провалившийся проект с кучей шикарных технических решений внутри - это не очень хорошо. И Анахорет в целом, и я лично, хотя и приобретаем больше позитивного опыта программирования, но, к примеру, сильно теряем в области портфолио.

Что очень мешает? Нереально бесит переключение контекстов. Мои наивные мечты о переключении контекста раз в сутки сродни мечтам Ассоль - в какой-нибудь сказке они могли бы и сбыться. На практике, если я не сижу рядом с кем-то, разговаривая, разработчики всех проектов дёргают меня с периодичностью инъекций личинок в инкубаторы зерга. Да в принципе, если с кем-то засижусь, происходит то же самое. "Дима, давай посоветуемся". "Дима, что сейчас лучше делать?". "Дима, как ты думаешь?". В пятницу вечером я хотел выделить себе три часа в конце дня разгрести трекер проекта Turbine. Я смог начать это делать, когда из этих трёх часов осталось сорок минут. Из-за этого я вообще не могу сосредоточиться на чём-либо. Причина и решение это проблемы вполне очевидны. Причина - фиговый я менеджер пока что. Учусь. Слишком много микроконтроля. Решение - надо лучше распоряжаться временем, лучше планировать и лучше ставить задачи. Ещё это зависит от уровня исполнителей - проект Влада гораздо менее чувствителен к контролю, чем проект Жени. Но тут уж какой топор есть, так из него уху и варить.

Вижу ли я перспективы - да, вижу. Научусь я быть менеджером. Станет у меня всё лучше получаться. Доведу проекты до их запусков. И если мне не дадут новых проектов взамен этих, у меня начнёт появляться свободное время. Может быть, его даже хватит, чтобы попрограммировать.

Чего бы мне хотелось? Мне нравилось быть программистом. Мне нравится то, что я делаю сейчас. Мне намного больше будет нравится это же занятие, когда, как я и сказал, проекты дойдут до релиза, а я научусь управлению проектами и времени станет больше.

Программировать мне всё же нравится больше. И если бы я получил новый проект сам для себя или с одним равным напарником, или с одним джуниором на обучение - был бы доволен.   Счастлив был бы, если бы этот проект ставил передо мной наукоёмкие задачи - обработка естественных языков, распознавание образов или речи, написание кодека, базы данных, компилятора, параллельных вычислений... Но об этом я напишу в другой раз.

Резюме. В том виде, в котором я сейчас работаю, я не кто иной, как менеджер, и больше никем быть не могу. Программировать некогда, и не всегда есть время посмотреть код, который пишут исполнители. Возможные пути решения этой проблемы конфликтуют с другими целями, стоящими перед этой программой или требуют отсутствующих в данный момент ресурсов. Поставленный руководить тремя-четырьмя проектами, из которых более одного не вышло в продакшн, сеньор будет вынужден заниматься исключительно менеджерскими обязанностями, под которыми я понимаю - коммуникации, обучение исполнителей, планирование итераций и релиза.