Вот что писал еще в 2000 году Джоель Спольски (Joel Spolsky) о своей профессии:
1 Не выдвигайте кодировщика на должность менеджера проекта. Умения необходимые, чтобы быть хорошим менеджером проекта (грамотный русский язык, дипломатия, понимание рынка, сопереживание пользователю и хорошие идеи пользовательских интерфейсов), это очень редко умения хорошего кодировщика. Конечно, некоторым удается и то и другое, но это редкость. Стоящие хорошие кодировщики, продвинутые на другую должность, которая заставит их писать на русском, а не на C++, это классический случай Принципа Питера): работники двигаются вверх по карьерной лестнице до своего уровня некомпетентности.
2 Не позволяйте маркетологам быть менеджерами проектов. Не в обиду, но, я думаю, мои читатели согласятся, что у хороших маркетологов редко есть хорошое понимание в вопросах технологий, достаточное, чтобы придумать продукт.
По существу, менеджер проекта – это отдельный путь карьеры. Все менеджеры проектов должны быть технически очень грамотными, но они не обязаны быть хорошими кодировщиками. Менеджеры проектов вникают в пользовательский интерфейс, встречаются с клиентами и пишут спецификации. Им надо ладить с очень разными людьми – от «слабоумных» клиентов до раздражающих отшельников-программистов, которые приходят на работу в форме из сериала «Star Trek» и до напыщенных менеджеров по продажам в 2000-долларовых костюмах. В чем-то менеджер проекта подобен клею в команде программистов. Харизма – вот ключевой элемент.
3 Кодировщики не должны отчитываться менеджеру проекта. Это коварная ошибка. Как менеджер проекта Microsoft я придумывал стратегию Visual Basic (VBA) для Excel и полностью расписывал её до мельчайших подробностей, как VBA будет реализован в Excel. Моя спецификация разбухла примерно до 500 страниц. На пике разработки для Excel 5.0 я оценил, что каждое утро примерно 250 человек приходили на работу и в основном претворяли в жизни эту громадную спецификацию, которую я написал. У меня не было ни малейшего представления, кто все эти люди, но было около дюжины людей в команде Visual Basic исключительно и только пишущих документацию по нему (не считая команды, пишущей документацию со стороны собственно Excel, или сотрудника с полной занятостью, отвечающего за перекрестные ссылки в файле справки). Невероятным было то, что я был на самом дне иерархии отчетности. Да, да. НИКТО мне не отчитывался. Если я хотел, чтобы люди что-то сделали, то нужно было убедить их, что это как раз то, что нужно сделать. Когда Бен Валдман (Ben Waldman), ведущий разработчик, не хотел делать что-то, что я занёс в спецификацию, он просто-напросто не делал этого. Когда тестеровщики жаловались, что я указал в спецификации нечто, что невозможно полностью протестировать, я должен был упростить это. Если бы хоть кто-то из этих людей был бы должен мне отчитываться, продукт не получился бы таким хорошим. Кое-кто из этих людей счёл бы неуместным предугадывать вышестоящего. Иной раз я мог бы просто надавить и, по самомнению или близорукости, приказать им делать по-моему. Но все было устроено так, что у меня не было другого выбора, кроме достижения единодушного согласия. Такая форма принятия решений была лучшим способом начать получать правильные вещи.
Источник: русский перевод Дмитрия Бакая.
