Судя по всему менеджер проектов - это человек, которому не наплевать на результат работ, наверно ему больше всего не наплевать после клиента и PM заставляет всех достигать необходимого результата. 

Вот так и становятся - тем кому не пофиг, начинают подбивать всех делать и делать лучше.

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

История из трех примеров:

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

Компания 2: уволился, попросил расчет - денег нет. Мы считаем, что ты плохо работал, что мы рассчитаемся с тобой тогда, когда клиент отдаст денег за проект и все в таком духе со скандалами.

Компания 3: компания развалилась. Директор продал 2 машины и квартиру, чтобы рассчитаться со всеми долгами. 

Вывод: не все директора понимают, то когда они кого-то нанимают, начинают нести ответственность за финансовое благополучие этого человека - он ведь должен работать на 100% в самое актуальное рабочее время, а не левачить везде и всегда в надежде вытянуть немного денег, чтобы не сдохнуть с голода.

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

Большинство же прикидывается шлангом, когда им надо отдавать деньги.

Часто в вакансиях требования к кандидатам на должность менеджеров проектов в IT (PM) - хорошая техническая подготовка, она же техническое образование.

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

Исторически я конечно понимаю, что первые менеджеры проектов пошли из программистов, а они в свою очередь выпускники технических вызов с определенным специфическим типом мышления. Лучшие из таких менеджеров (заметьте не в плане программирования) стали иконами в области управления IT проектами и руководства программистами. Но дало ли такой эффект техническое образование или это норма в % людей, кто занимается этим и тех на кого молятся?

Что же делает менеджер проекта и чем он отличается от team lead, должен ли каждый менеджер сначала быть лидером команды разработчиков (team lead)? Итак далее рассмотрим сценарии не программистских ролей на проекте.

Проблема 1: надо посчитать (estimate внутренний) срок выполнения проекта или итерацию. Этим должен занимать PM, но teamlead может ему активно помогать. Если PM ранее был программистом, то он сам может прикинуть объем работ и сколько это делать по времени и тут ему конечно его технические навыки пригодятся, но приблизит ли это просчитанную дату к реальности (то за сколько времени сделает это команда) - нисколько. Не технический PM узнает оценки (estimate) сроков у каждого в команде - да, это будет не совсем правильная цифра, но более адекватная и еще это немного вовлечет программистов в процесс и у них появиться личная ответственность, в отличие от авторитарного первого варианта. Получается, что от технических навыков PM в вопросе планирования сроков - только вред.

Проблема 2: есть задача бизнеса и её надо реализовать. Технический PM уже видит решение и как ему кажется - оптимальное. Не технический PM идет с проблемой к команде и они могут найти лучшее решение. Тут все зависит от умения вести диалог, но в целом первый вариант дает зачастую не самый лучший результат (ну кроме, тех случаев, когда PM - единственный грамотный специалист). И снова технические знания проиграли.

Проблема 3: программист долго бьется над куском кода и ему нужна помощь. Технический PM сразу бросается помочь и получает на свои плечи проблему - он часто пишет решение за человека, а значит отвечает за работоспособность и поддержку кода. Не технический PM, как бы не хотел, лично помочь не может, поэтому ищет кого бы припрячь и тут о чудо, у нас же есть team lead, а чего он отлынивает от своих прямых обязанностей - припрячь. Технические знания так и не пригодились.

Проблема 4: программист сообщает об какой-то серьезной проблеме (epic failure). Вот тут не помешали бы технические знания, чтобы общаться на одном языке, и да PM должен немного знать сленг и понимать, что вообще происходит, но это понимание поможет решить проблему или нет. Скорее нет, т.к. когда программист становиться руководителем, его навыки программирования притупляются, соответственно какой из него миссия. Не технический же PM будет искать опять же того, кто сможет решить проблему - или team lead или собрать людей (meeting), чтобы совместными усилиями решить проблему.
и т.д., проблем много, а техническое образование не делает из менеджера лучшего менеджера по сравнению с тем у кого другое образование.

Можно конечно вернуться к теме, что же делает из заурядного человека отличного менеджера, но скорее всего это не относиться к техническому образованию, а например, к эмоциональному интеллекту . Так почему же такие требования? Возможные причины:

1. менеджеров стараются растить внутри компании, а это скорее всего программисты
2. менеджеры по персоналу (hr) не знают другой мантры, как человек с техническим образованием (менеджер) всегда поймет другого человека с техническим образованием (программист) и на их голову меньше проблем, но видимо, понимания мало, нужна правильная работа (предыдущие примеры).
3. заблуждение: если человек не разбирается в специфик, то его не будут уважать и он не сможет быть лидером, но лидер определяется не уважением со стороны, а скорее своей моделью поведения, да и не всегда нужен воинствующий альфа-лидер для команды

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

Есть еще подтип: "ну как там дела?", "а помнишь мы говорили, ты сделал?" и пр. подстраховщики.

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

А вам не надоело жить по дедлайнам?

Моя работа часто ставит меня в весьма жесткие рамки: приходится работать и на работе и еще часть работы делать дома (многие вещи требуют сосредоточенности, что не всегда получается в рабочее время) . Конечно есть варианты со своими плюсами и минусами:

• носить с собой ноутбук/нетбук. Плюсы: рабочее окружение всегда с тобой. Минусы: это все равно вес, если ноут единственный комп, то на нем одинаково комфортно и работать и отдыхать (смотреть кино, играть в игры) психологически не сильно получиться.
• носить с собой флешку: Плюсы: документы всегда доступны, можно использовать свободное место плеера. Минусы: можно ненароком забыть дома или на работе, например, воткнутой в разъем с тыльной стороны системного блока.
• использовать online хранилище. Плюсы: доступно с любого компьютера. Минусы - нет интернета, нет файлов, web-интерфейс.
• удаленный файловый сервер (вариант для маньяков). Плюсы: столько места сколько хочешь, разные возможности доступа. Минусы: сложно развернуть, нужного много знать, чтобы это сделать, поддерживать в рабочем состоянии тоже самому.

Хочу поделиться опытом работы с файлами через Dropbox. Все весьма изящно:хочешь работай через web-интерфейс, хочешь через специальную программу-клиент (Windows, Mac, Linux), который создает специальную папку в Моих документах, куда можно кидать файлы. Если отрубится интернет, доступ к файлам не пропадает и как только он появится, то они тут же синхронизируются с сервером.

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

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

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

Немного в экскурс вопроса: для чего нужны руководители. Как я понимаю это, руководители - люди, которые имеют в голове самую полную картину (назовем это vision) того бизнеса или его уровня, в котором он работает. Значит это следующее, человек тогда становиться у руля, когда знает куда плыть и как устроено судно и принимая всю ответственность за достижение цели пути и за здравие команды и за курс движения.

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

Можно ли обойтись без руководителя - как показывает практика (Agile/Scrum), можно. Но для этого нужна хорошо сработавшаяся команда ответственных людей в условиях, когда в принципе всем довольны (самой работой, должностью, зарплатой, взаимоотношение в коллективе), готовы и очень много общаются, чтобы скоординировать действия . Но это сложно достижимо, поэтому от руководителей никуда не деться.

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

Руководитель среднего звена (линейный менеджер или руководитель отдела, проекта).
Мне нравиться приводить в пример старшего инспектора Клюшо (серия фильмов про Жандарма (1964-1970) с Луи де Фюнесом) . Суть его поведения такова - командовать подчиненными и льстить начальству. Такие пойдут далеко, но их любить никто не будет и на призыв поработать на выходных - если и будут то, только из под палки. Совершенно другая модель поведения это наставник - старший коллега, который пытается помочь вам делать ваш работу лучше, он может открыть глаза вам на проблемы, помочь организовать саморазвитие, решить оперативные проблемы, просто поднять настроение, дать разъяснение. Тут есть 2 момента: руководитель получает больше потому, что у него больше ответственности за результат работы; руководитель среднего звена или мечтает о директорском кресле (в хорошем смысле, т.е. хочет стать директором) или любит власть-деньги или действительно считает своим предназначением руководить определенными работами так, чтобы получить лучший результат. Все зависит от его мотивов и мотивации. Соответственно, лучший руководитель тот, кто занимает свое место правильно, и не пытается заткнуть людей под себя, а разумно предлагает всем за зарплату решить некую проблемы, например, ограничение количества ВИЧ-инфицированных путем производства ударного количество изделий №2 с лучшим качеством, чтобы не рвались в ответственный момент.

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

5 качеств руководителя:

1. Прямота и честность 
2. Уважение к тем, с кем работает
3. Понимающий и душевный человек
4. Не бросать обещаний на ветер, четко выполнять свои обязательства - у подчиненных должно быть доверие
5. Любить свое дело, свой бизнес и все, что с ним связано

Многое в тайм-менеджменте для руководителей (а им он нужен больше всего) упирается в такой принцип, как делегирование. В идеале он гласит, все что можно поручить - поручайте. Все вроде бы правильно, и если у вас работает несколько человек в подчинении и получают ежемесячную зарплату, то даже  вполне закономерно, отдать им часть работы (может немного повысить з/п) и освободить свое время для более важных вещей.
Все обстоит иначе, когда за каждое поручение надо назначать цену и и платить деньги из своего кармана, т.е. по сдельной форме оплаты труда. Конечно, многие вещи все равно нужно поручить, но возникает вполне резонный вопрос стоит ли по максимуму делегировать или нет.
Скорее всего вопрос просто в деньгах. Если вы будете отдавать 1/4 ваших доходов на оплату делегированных задач, но при за освободившееся время сможете увеличить свой доход (в динамике увеличивать больше, чем в динамике увеличивается расход на делегирование), тогда это имеет смысл или надо переводить подчиненных на зарплату. Как-то так.

В борьбе с человеческой глупостью и недальновидностью родилась истина - надо развивать навык убеждения. Это выражается (оп отношению к работе) в:

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

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

• понять какое будет идеальное решение (в разумных пределах, возможно даже выходя немного за ограничения)
• понять, что по минимуму надо сделать
• понять какое может быть оптимальное решение

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

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

Стандартная ситуация: 4 и более проектов, которые ведет менеджер проектов. Ведет в данном случае раздает задачи и контролирует их выполнения, согласовывает все нюансы. При этом ворох всяких задачи и контролей по ним просто достаточно широк. При этом множество задач нуждаются в согласовании и дальнейшем расширении или декомпозиции с последующим согласованием.( Read more... )

Недавно провел хронометраж полного рабочего дня. И выяснил для себя несколько интересных особенностей.
( что из этого вышло )

Недавно на WishList появилась забавная вещица - отрывные листочки с надписью: I will do one thing today. thing: . Я решил продолжить эту мысль.
( что именно я предлагаю )

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

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

Часто клиент обращается с проблемой: срочно нужен сайт, нужен еще на вчера. Хотят, чтобы уже через месяц или два появился.

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

Не знаю, как у кого, но меня после прочтения книги Девида Алана "Getting Things Done" возникла необходимость управления своими делами с помощью уже готовой web-based системы. Практическое сравнение таких систем приводится в данном посте.