Первая часть заметок под общей темой “Почему я не хочу быть начальником?” (следующая часть здесь)
Сегодня речь пойдет о двух вещах, которые, как мне кажется, являются двумя сторонами одной и той медали.
Итак, сторона первая. Что требуется от хорошего инженера-программиста? Принимать правильные технические решения. Для чего зачастую приходится очень глубоко погружаться в проблему и очень долго, тщательно и всесторонне рассматривать различные способы ее решения, чтобы затем остановиться на каком-то одном. Погружение может потребовать изучения большого количества материалов (например, штудирование нескольких талмудов с документаций и стандартами). Кроме того, дело может свестись не к выбору какого-то готового решения, а к рождению собственного варианта.
Помню, как в 97-м или в 98-м пытался решить проблему эволюции схемы данных в своей объектно-ориентированной БД. Т.е. пользователь сначала описывает схему БД на языке описания данных, затем наполняет БД данными, затем описывает новую схему на том же языке, а сама БД определяет, как схема изменилась и как следует преобразовать данные. И чтобы пользователю не приходилось вручную вписывать инструкции вида alter table… add… или alter table… drop column… Просто БД должна была сравнить две схемы и сама решить что к чему.
Я рожал такое преобразование около месяца. Занимаясь, по сути, только им. На все остальное не оставалось сил. В мусорку отправилась толстенная пачка бумаги формата A4. Но алгоритм таки был получен, реализован и протестирован.
Вот это, я считаю, и является главной добродетелью хорошего разработчика – погрузиться в задачу так, чтобы ничего больше не существовало вокруг, и сделать в конце-концов конфетку. Чтобы у самого была 100% уверенность в том, что лучше ты бы уже не смог.
А с чем сталкивается начинающий начальник? С тем, что ему не дают возможности отрешиться от внешнего мира и уйти в себя чтобы что-то там родить. Не до того. То один подчиненный что-то спросит. То второй просит принять окончательное решение в каком-то споре. То начальство просит высказаться по какой-то проблеме. То пятое, то десятое. Причем, с увеличением количества подчиненных и числа проектов промежутки между “внезапными вбрасываниями” не то, что стремятся к нулю, они грозят стать отрицательными! :)
Т.е. от начальника требуется умение очень быстро переключаться между разными проблемами и быстро принимать решения, способность делать выбор даже при огромном недостатке информации.
На мой взгляд, здесь проявляется главное отличие “заточенности” мозгов инженера и руководителя. Инженеру нужно уметь вобрать в семя максимум наиболее подробной и точной информации, чтобы затем упорядочить и отсортировать ее. Тогда как руководителю нужно суметь обойтись минимумом (зачастую поверхностной) информации.
Ну а теперь сторона вторая. Хочу приплести аналогию с легкой атлетикой, где есть спринтеры и стайеры. Такое деление возникло не случайно, это следствие особенностей организма – кто-то способен на короткие, требующие мгновенного высвобождения энергии нагрузки, кто-то на длительные, выматывающие. И в истории спорта (особенно современного) вряд ли найдется много примеров, когда успешный спринтер после побед на 100-метровках переквалифицировался бы в успешного стайера и побеждал бы в 5-километровом стипльчезе.
Что-то подобное, имхо, прослеживается и в разработке ПО. Только я бы это аналогию развернул, подозреваю, неожиданным образом. Я думаю, что программисты – это спринтеры. Работа программиста – как серия 400-метровок – напрягся (погрузился в задачу), расслабился (доделываю предыдущую задачу и присматриваюсь к новой), напрягся (погрузился), расслабился…
Тогда как начальники – это стайеры, бегуны на длинные дистанции с препятствиями – бежим, бежим, прыгнули, бежим, бежим, еще раз прыгнули, опять бежим, бежим, прыгнули снова, опять бежим, снова бежим… И так из проекта в проект.
Ну а теперь к сухому остатку всего вышеизложенного потока сознания: переход от разработки к управлению разработкой – это как переквалификация из спринтеров в стайеры. Хорошо, если возможности организма (мозгов) позволяют это сделать.
У меня совершенно противоположное впечатление. Инженер - стайер, который бежит час-другой, пока не закончит какую-то задачу или не выйдет из потока. Начальник - это даже не спринтер, а баскетболист или хоккеист, у который постоянно решает, какие-то локальные задачи, но должен еще держать в голове план игры.
ОтветитьУдалить@fragment:
ОтветитьУдалить>Инженер - стайер, который бежит час-другой, пока не закончит какую-то задачу или не выйдет из потока.
Это если рассматривать какую-то конкретную часть проекта (весьма небольшую при том). А если брать проект протяженностью от шести месяцев и больше, то инженер вряд ли будет считаться стайером.
>Начальник - это даже не спринтер, а баскетболист или хоккеист
Не сомневаюсь, что в других видах спорта для начальника можно найти более точную аналогию.
Прочтите книгу "Одноминутный менеджер". Если вы её не читали. Очень полезная штука. А от себя добавлю - начальнику нужна скорее не техническая гениальность, а владение терминологией области, которой он управляет, и талант разбираться в людях. Как можно отличить отличную техническую идею от прожекта ? Как определить, что человек, рассказывая о технических проблемах, не водит вас за нос ?
ОтветитьУдалить