воскресенье, 25 марта 2012 г.

Менеджеры и разработчики

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

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

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

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

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

Я долгое время думаю над тем, как заставить разработчиков любить менеджеров. Это очень сложно, ведь большинство разработчиков, во-первых, видят в менеджерах чуть ли не своих личных врагов, так как именно от них исходят замечания по только что сделанным прекрасно работающим задачам! Во-вторых, потому что менеджеры обычно мало понимают в тонкостях хитросплетений технологий, и им надо долго объяснять, как тупым, почему, к примеру, для сайтика на PHP лучше Apache или Nginx, но не IIS, а разработчики обычно ценят знания и опыт, а не искусственно организованную субординацию.

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

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

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

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

    А в целом, да, хорошо, что есть менеджеры проектов и продаж, без них проекты были бы похожи на постоянный ад. :)

    ОтветитьУдалить
    Ответы
    1. Тестирование у нас есть отдельное, но вот внедрением занимаются сами программисты. Уверяю тебя, даже наступив с десяток раз на одни и те же грабли, мы продолжаем с завидным упорством наступать на них снова и снова :) С каждым новым проектом думаем, что вот да, сейчас всё будет круто. Но потом начинается странная неведомая деятельность, связанная с отклонениями от тз, странными прихотями клиентов, внезапных сверхсрочных задач от менеджеров, и так далее. И потом внезапно обнаруживается, что ручка граблей уже пролетела половину пути! Как перестать делать одни и те же ошибки, я не знаю. Конечно, я склонен винить всех вокруг, но не себя. Дизайнеры нарисовали хуй знает что, верстальщики сверстали хуй знает как, постановки задач вообще не вяжутся с тз, клиент внезапно меняет мнение... хотя, конечно, разработчики тоже виноваты во всей это неведомой хуйне. Не предусмотрели возможность появления внезапных хотелок и недостаточно гибко всё запрограммили, да и ошибок налепили. Не ошибается тот, кто ничего не делает.

      Удалить

Ублюдочный Гугл поломал форму комментариев. Извините.