Computerworld, США

Об отношении к людям, которые не пишут код и не поставляют решений

Время от времени меня спрашивают, что делать с людьми, которые «ничего не производят»? Вопрос звучит примерно так: «Как вы поступаете с сотрудниками, которые не принимают непосредственного участия в реализации проектов? Они хороши в техническом анализе, написании документации и формировании стратегии, но не поставляют решений. Я не могу позволить себе держать их».

Фактически у вас в вежливой форме пытаются узнать, что следует делать с бесполезными людьми?

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

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

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

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

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

«Я тебя совершенно не понимаю, — сказал менеджер проекта. — Первые полгода нашей совместной работы ты был для меня как гвоздь в одном месте. А по прошествии этого периода мы разговаривали довольно редко, и ты превратился в одного из самых эффективных сотрудников. Чем вызвана такая метаморфоза?»

«Просто я наконец понял, что вы хотите, — пояснил я. — Мы смотрим на мир по-разному. Поначалу я ничего не понимал из того, что вы спрашивали у меня, поэтому и вынужден был задавать миллион вопросов. Но когда я понял, что вы пытаетесь сделать, мне уже не составляло труда делать то же самое. Не всегда я был согласен с вашим подходом, но если он совпадал с моим видением ситуации, это было прекрасно».

Пол Глен — консультант по вопросам управления информационными технологиями. Электронную почту ему можно направлять по адресу info@c2-consulting.com

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

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

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

Производство технологических решений не есть задача ИТ-организаций. Нам нужно обеспечить хорошую и эффективную работу предприятия. А технология — лишь средство для достижения этой цели. И если пользователям нужна документация для эффективного применения технологии, то написание этой документации должно проходить как «настоящая работа».

Десять лет назад мне часто приходилось слышать подобные слова, высказанные в адрес руководителей проектов. Клиенты не хотели оплачивать их труд. Менеджеры проектов не занимались написанием кода, поэтому никто не знал, что же они делают. Естественно, в такой ситуации их не считали настоящими работниками.

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

Представьте себе, на конференции финансовых директоров — или даже программистов — вы вполне могли бы услышать схожие вопросы: «Что мне делать с моим ИТ-менеджером? Я не имею представления о том, чем он занимается. Кода он не пишет, и мы не можем позволить себе держать его».