пятница, 17 декабря 2010 г.

[work] Быть начальником? Глубокое погружение vs быстрое переключение

Первая часть заметок под общей темой “Почему я не хочу быть начальником?” (следующая часть здесь)

Сегодня речь пойдет о двух вещах, которые, как мне кажется, являются двумя сторонами одной и той медали.

Итак, сторона первая. Что требуется от хорошего инженера-программиста? Принимать правильные технические решения. Для чего зачастую приходится очень глубоко погружаться в проблему и очень долго, тщательно и всесторонне рассматривать различные способы ее решения, чтобы затем остановиться на каком-то одном. Погружение может потребовать изучения большого количества материалов (например, штудирование нескольких талмудов с документаций и стандартами). Кроме того, дело может свестись не к выбору какого-то готового решения, а к рождению собственного варианта.

Помню, как в 97-м или в 98-м пытался решить проблему эволюции схемы данных в своей объектно-ориентированной БД. Т.е. пользователь сначала описывает схему БД на языке описания данных, затем наполняет БД данными, затем описывает новую схему на том же языке, а сама БД определяет, как схема изменилась и как следует преобразовать данные. И чтобы пользователю не приходилось вручную вписывать инструкции вида alter table… add… или alter table… drop column… Просто БД должна была сравнить две схемы и сама решить что к чему.

Я рожал такое преобразование около месяца. Занимаясь, по сути, только им. На все остальное не оставалось сил. В мусорку отправилась толстенная пачка бумаги формата A4. Но алгоритм таки был получен, реализован и протестирован.

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

А с чем сталкивается начинающий начальник? С тем, что ему не дают возможности отрешиться от внешнего мира и уйти в себя чтобы что-то там родить. Не до того. То один подчиненный что-то спросит. То второй просит принять окончательное решение в каком-то споре. То начальство просит высказаться по какой-то проблеме. То пятое, то десятое. Причем, с увеличением количества подчиненных и числа проектов промежутки между “внезапными вбрасываниями” не то, что стремятся к нулю, они грозят стать отрицательными! :)

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

На мой взгляд, здесь проявляется главное отличие “заточенности” мозгов инженера и руководителя. Инженеру нужно уметь вобрать в семя максимум наиболее подробной и точной информации, чтобы затем упорядочить и отсортировать ее. Тогда как руководителю нужно суметь обойтись минимумом (зачастую поверхностной) информации.

Ну а теперь сторона вторая. Хочу приплести аналогию с легкой атлетикой, где есть спринтеры и стайеры. Такое деление возникло не случайно, это следствие особенностей организма – кто-то способен на короткие, требующие мгновенного высвобождения энергии нагрузки, кто-то на длительные, выматывающие. И в истории спорта (особенно современного) вряд ли найдется много примеров, когда успешный спринтер после побед на 100-метровках переквалифицировался бы в успешного стайера и побеждал бы в 5-километровом стипльчезе.

Что-то подобное, имхо, прослеживается и в разработке ПО. Только я бы это аналогию развернул, подозреваю, неожиданным образом. Я думаю, что программисты – это спринтеры. Работа программиста – как серия 400-метровок – напрягся (погрузился в задачу), расслабился (доделываю предыдущую задачу и присматриваюсь к новой), напрягся (погрузился), расслабился…

Тогда как начальники – это стайеры, бегуны на длинные дистанции с препятствиями – бежим, бежим, прыгнули, бежим, бежим, еще раз прыгнули, опять бежим, бежим, прыгнули снова, опять бежим, снова бежим… И так из проекта в проект.

Ну а теперь к сухому остатку всего вышеизложенного потока сознания: переход от разработки к управлению разработкой – это как переквалификация из спринтеров в стайеры. Хорошо, если возможности организма (мозгов) позволяют это сделать.

3 комментария:

Unknown комментирует...

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

eao197 комментирует...

@fragment:

>Инженер - стайер, который бежит час-другой, пока не закончит какую-то задачу или не выйдет из потока.

Это если рассматривать какую-то конкретную часть проекта (весьма небольшую при том). А если брать проект протяженностью от шести месяцев и больше, то инженер вряд ли будет считаться стайером.

>Начальник - это даже не спринтер, а баскетболист или хоккеист

Не сомневаюсь, что в других видах спорта для начальника можно найти более точную аналогию.

TheIvan комментирует...

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