vit_r (vit_r) wrote,
vit_r
vit_r

Categories:

Должен ли ИТ менеджер программировать? (3)

Здравствуйте!

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

Да, ещё одно пояснение: это не готовый текст. Если когда-то дойдёт до книги, она будет на английском и без матов. Пока что я просто в черновом варианте накидываю материал, а заметки к отсутствующим главам и темам. Остальное или пропускается, или упоминается вскользь.

Те, кто хочет, может начать с начала.
Для остальных

Часть вторая. О вреде личного общения

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

Чтобы разобраться с этой проблемой, рассмотрим процесс с нейтральных позиций.

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

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

Итого, у нас остаётся канал получения информации и канал управляющий. Для начала остановимся на втором.



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

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

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

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

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

К сожалению, всё портят обратные связи.

Программист - это не беспристрастная безошибочная машина. Процесс выдачи информации подчинён эмоциям. А они при разговоре с начальством редко когда бывают положительными.

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

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

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

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

Кстати, именно оттягивание атак менеджмента является основной для состояния "девяностопроцентной готовности", в котором многие проекты пребывают годами.

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


"пять процентов"
"мы уже немного покопались в этом"

"тридцать процентов"
"мы потратили на это немного времени"

"пятьдесят процентов"
"мы потратили на это много времени"

"семьдесят процентов"
"мы усилено работаем, только не надо приставать к нам со сроками"

"девяносто процентов"
"только не волнуйтесь, работа идёт полным ходом"

"девяносто пять процентов"
"Да знаем мы, знаем: всё давно должно быть готово. Вы думаете это так просто?"

"практически сто процентов"
"Уф! Мы спихнули всё в отдел тестирования и они ещё не успели посмотреть."



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

Почему ж тогда превышение сроков в большинстве проектов не столь ужасно? И тут мы можем вспомнить ещё одно полезное слово из теории систем: "адаптация".

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

Самым великолепным был начальник разработчиков, объявивший, честно глядя в глаза заказчику, что отныне любой бильд, собранный в назначенную в плане дату, является релизом. Можно формулу успеха сформулировать короче: "Вы платите деньги за то, что работаем мы, а не за то, что работает программа". Впрочем, это уже другая тема. Про волшебное слово "Agile" разговор будет в другом месте. Назад к нашим баранам.

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

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

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

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

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

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

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

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

К счастью для софтверных проектов, сопротивляемость систем уравновешивает их непредсказуемость.

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

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

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

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

Отметив несомненную силу воздействия менеджера на подчинённого, всё-таки не забудем, что в разговоре с подчинённым менеджеру ценную информацию не получить. Переписка по компьютеру, многочисленные формы и отчёты нам тоже реальность разъяснят не сильно. Оставив пока в стороне вопрос, стоит ли платить такие деньги только за постоянные бездоказательные уверения в том, что всё идёт по плану, направим стопы к другой цитадели менеджмента. В следующей части речь пойдёт о непродуктивности коллективного мышления.
Tags: it, management, ru
Subscribe
  • 15 comments
  • 15 comments

Comments for this post were locked by the author