Какая разница, какие погоны висят на человеке? Тимлид он или руководитель отдела — если перед вышестоящим за успех он отвечает, то у него есть роль руководителя проекта. А по поводу коллективной ответственности — предположим, с одним из проектов возникают серьёзные проблемы. Кого ваш руководитель вызывает на ковёр? Весь коллектив выстраивает? И они хором должны пообещать что-то хорошее? ) Ну вот честно, не представляю я такой ситуации. Это всё быстро заканчивается, как только у собственников возникает серьёзный риск потери серьёзных денег.
Если под менеджером проекта понимать того единственного человека, который отвечает за успех проекта перед руководством или акционерами, то такая роль никогда не исчезнет. И не важно, какая методология используется, где рисуются тикеты или диаграммы Ганта и какой размер у проекта. Как только ответственность становится размытой или коллективной, это первый шаг к провалу.
1) распределённая команда
2) у членов команды разный опыт как на проекте, так и в профессии
3) смена приоритетов и изменение требований
4) ужесточение сроков
5) необходимость перестроить работу в связи, например, с болезнью одного из ведущих разработчиков
…
Список можно продолжать. Если тут не будет правильно организованных митингов, то проект будет гарантированно провален. Если только, конечно, команда не состоит из одних самоорганизующихся супергероев-сеньёров-телепатов с неограниченным ресурсом времени.
По какой-то причине, в статье сделан упор на работу с чем угодно, но не с собственно командой, с людьми, которые делают основную работу по проекту. Сколько раз приходилось сталкиваться с ситуацией, что за проект берётся вроде бы грамотный человек, который большинство описанных вопросов так или иначе закрывает, но к своей команде относится как к ресурсам, которые подобны роботам — должны делать то-то и то-то, по процессу. Может это где-то и работает, но обычно от руководителя проекта требуется тесный контакт с командой и не только на уровне постановки задач и не только с лидами. Команду нужно мотивировать, знать, чем она живёт, отслеживать внутрикомандные риски, планировать состав и качество команды, объяснять ей что за проект мы делаем. Скажем, если говорить о проектах из линейки «Безопасный город», то энтузиазма и осознанности в своих действиях у команды будет гораздо больше, если они будут понимать, что результатом их работы будет система, которая будет спасать человеческие жизни, нежели чем просто выполнение плана по прибыли для акционеров своей компании или формальные кипиаи. И по 12 часов будут работать с другим пониманием, а не из-под палки. Да, всё, что приведено в статье, безусловно, важно, но если руководитель проекта не установит хорошего контакта со своей командой и команда не увидит в нём лидера, за которым хочется идти, то всё остальное будет иметь мало смысла.
На мой взгляд здесь универсального рецепта нет. Есть подход — если проблема возникает системно и частоту ее возникновения можно посчитать, как с отпусками, то считаем. Если в конкретной компании системно возникают проблемы с продлением контрактов и мы можем как-то их спрогнозировать, скажем, опираясь на статистику, то да, это стоит делать. Во всех остальных случаях, как правило, достаточно, как тут уже предлагали коллеги, закладывать некий интегральный риск.
Все верно говорите. Это если ограничиваться жизнью внутри компании. А за ее пределами? Я понимаю, что не все компании, особенно большие и очень большие, готовы продавать свои ресурсы на открытом рынке или даже партнерам. В этом случае, обычно, спасают внутренние проекты компании, на которые просто так никто ресурсы не выделит, а вот если ресурс простаивает — пожалуйста. В таком случае это уже сложно назвать неоправданными затратами на содержание простаивающих/недозагруженных ресурсов, это уже инвестиции в свой продукт/проект.
Ну, недоговаривать мне смысла нет, а насчет подсвеченных рисков — конечно, они есть. Но я весь комплекс этот рисков упаковал в формулировку «негарантированное качество ресурсов», которое, как правило, нужно компенсировать более изощренным управлением, что и отражено в «дорогое управление» и «накладные расходы на администрирование».
По-моему тут все достаточно просто. Компания заинтересована в том, чтобы ее сотрудник хорошо работал. Сотрудник будет хорошо работать, если у него интересная задача, хорошие условия труда и он не отвлекается ни на какие посторонние мысли, типа: чем кормить семью, куда пойти полечить зуб, когда вырваться с работы и подождать слесаря, когда съездить в автосервис и т.п.
Хорошо бы предусмотреть возможность блокировки звонков по категории 2Gis. Если я не хочу выслушивать рекламные объявления о разного рода кредитах и т.п.
Да здесь миллиард долларов имеет символический смысл. Дело совсем не в миллиарде. Оракл умеет зарабатывать деньги и за пределами стен суда. Первую причину автор привел в самой статье — решение суда может стать прецедентом и в этом случае компании-последователи, имитирующие интерфейсы лидеров рынка, окажутся в очень уязвимой позиции. Вполне вероятно, что за Ораклом тут стоят и другие крупные компании. Я тут вижу еще и другую причину — Google успешно зарабатывает на Java и всем, что связано с этим языком. При этом, косвенно, через производителей девайсов, выплачивают дань Майкрософт. Почему бы подобную схему не организовать Ораклу? Неплохой доход и косвенная сопричастность к успеху динамичных друзей-конкурентов — разве это плохо?
Вопросы безопасности, конечно, имеют место быть, но это все решаемо. А насчет отстрела и мародерства — ну вы вспомните, как воспринимали изначально идеи электронной коммерции и вопросы доверия к тем, кому перечисляем деньги авансом за товар, а потом его ждем. Конечно, косяки бывают у всех и желающих обмануть других достаточно, но, как мне кажется, самосознание общества растет и такие вещи делать уже просто неприлично. А тот процент вандалов и желающих забрать себе или сбить аппарат вероятно будут учитывать в числе плановых потерь, как в торговле. В целом, бизнес обещает быть очень прибыльным, несмотря на эти риски. И, кстати, наверняка те, кто себе попробует забрать такой аппарат, лишит себя в дальнейшем возможности воспользоваться такой удобной штукой — выгода сомнительна. Ну и камеры на этой штуковине наверняка будут следить за ситуацией вокруг.
По теме собственной разработки трекера — в транспортной логистике есть серьезная проблема (во всяком случае, пару лет назад была) с такими устройствами. Экспедитору нужно следить за местоположением груза — чтоб не увели и чтобы водитель не вводил в заблуждение о своем местоположении. А поскольку экспедитор обычно арендует фуру, то у него не бывает доступа к GPS-оборудованию, даже если оно установлено в машине. Выход — кидать в груз такой вот трекер и следить за его местоположением. Проблем две — срок жизни аккумулятора трекера и минусовые температуры зимой. Если сделать трекер с хорошей батарейкой и устойчивый к отрицательным температурам, то у него будет очень неплохая рыночная ниша.
Людей набирали извне. Но сначала определились с платформой. Как — я описал. А под нее искали и девелоперов. И в этот период во весь рост встала проблема регионального HR-ИТ-рынка. А веб на Java — это скорее экзотика. Во всяком случае, в Самаре. PHP, Ruby — да. Java-опыт у людей больше промышленный, а не из веба.
2) у членов команды разный опыт как на проекте, так и в профессии
3) смена приоритетов и изменение требований
4) ужесточение сроков
5) необходимость перестроить работу в связи, например, с болезнью одного из ведущих разработчиков
…
Список можно продолжать. Если тут не будет правильно организованных митингов, то проект будет гарантированно провален. Если только, конечно, команда не состоит из одних самоорганизующихся супергероев-сеньёров-телепатов с неограниченным ресурсом времени.
Согласен, полезная добавка к чек-листу.
а сколько новых рабочих мест создается?