Мы создаем компанию чтобы что: получить прибыль или прокормить группу безработных товарищей?

Каждый альтруист знает какой объем он может сделать за период времени, а какой нет. Лентяи не знают ничего. Но вот, что самое забавное, что если вы теоретически можете сделать 20 дел в день, а в какой-то из дней сделаете 5, то вы будете считать, что этот день прошел не продуктивно. 
Правдиво и обратное: если кто-то знает, что вы можете больше, а делаете меньше, то он считает, что вы ленитесь. А если не знает, то меряет по себе, если сам делает больше, то считает, что вы непродуктивны, а если меньше, даже поражается насколько это вам удается быть таким продуктивным.
А вот реально сколько должен, обязан делать человек в день за те деньги, что ему платят, оценивает кто? В лучшем случае HR на основе какой-то статистики и метрик, в худшем субъективно руководитель и тут совсем немонятно как оно.

Многим людям (не все конечно, но большинству) хочется жить лучше. Возьмем вариант  с объективно лучше (материально), а не субъективно (духовно, типа радоваться малому). Это приводит к аналогии лучше=богаче.

Жизнь дает слишком мало опций:

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

Как действовать дальше? Если есть талант, то развивать его. Если нет, то развивать проф. навыки и пробовать открывать свой бизнес, не получится - не твое. Не проворонить удачу.

Наивно? Банально?

Судя по всему менеджер проектов - это человек, которому не наплевать на результат работ, наверно ему больше всего не наплевать после клиента и 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'ами и пр. При правильных взаимоотношениях контролировать не надо.