Например обычная иерархическая структура с профильными отделами или лабораториями. При условии что во главе отделов стоят наиболее опытные разработчики а не администраторы.
Это кстати то что PMBoK сразу отвергает, утверждая что это неэффективная структура но не приводя убедительных доказательств.
В теории и на бумаге всё так и есть. Реальность немного иная. Людей которые смогут и захотят всё это сделать, причем сделать качественно — очень мало. Всё что вы написали — очень важно. И бизнес ценности надо видеть, и конфликты разруливать, и проект полностью видеть. Вот только почему вы хотите что бы это делал руководитель?
Полностью видеть проект может только тот кто обладает квалификацией, разруливать конфликты — человек с авторитетом, который ещё надо заработать. Собрать зоопарк вместе — это вообще высшая квалификация, руководителям она обычно не доступна. Хотя бы потому что когда человек начинает руководить и перестаёт работать руками то квалификация теряется.
Прекрасно. Но давайте вернёмся к Ивану. Он прошёл у вас собеседование. Вот он приходит на работу и начинает работать. Вот что он делает? Конкретно? Например в первые две недели, когда Пётр с точностью до секунды выполняет поставленную перед ним задачу.
Когда я учился в институте (начало 90-х) нам рассказывали про системный подход. Если отвлечься от терминов — то примерно то же самое. В НИИ тоже было примерно то же самое, но опять же без модных терминов.
Так что проектный подход это просто модный термин. За ним стоит только одно — это система распределения денег. Собственно именно это является основным в PMBoK. Остальное — дымовая завеса. Где-то в какой то компании это сработало. Видимо в результате случайностей кто-то из авторитетных руководителей придумал схему и модный термин. У них получилось. А дальше просто образовался карго-культ. Вот давайте сделаем такие же названия и оно само образуется. И ещё метрики введём. И чем более непонятны метрики тем лучше.
Так что позвольте вам не поверить про наиболее эффективный подход. Проектный подход как то работает, он создаёт иллюзию контроля. Но считать его панацеей и серебрянной пулей как то странно.
Вы сейчас сказали самую главную вещь — ему руководство доверяет. Отсюда следует — что остальным не доверяют. Или скажем аккуратнее — доверяют меньше. Но это уже вопрос к руководству — зачем брать на работу людей, которым они не доверяют.
То что вы написали про руководителя проекта это конечно классическое определение. Но оно ещё как то может быть оправдано для больших проектов. Но не для проекта в котором задействовано четыре человека.
Я не зря спросил про квалификацию Ивана. Давайте всё таки выясним что он может делать. Основные вопросы:
1. Он является специалистом в предметной области?
2. Он является программистом?
3. Он работал вместе с Петром над спецификациями? Т.е. он вообще знает что в проекте твориться?
Пока из ваших ответов я понял что он занимается общим руководством, для меня это означает что он является совершенно бесполезным человеком в этом проекте. Из этого вытекает следствие, что самое лучшее что он может сделать это уехать в отпуск. Это нужно что бы не мешаться под ногами у программистов в самый ответственный момент.
Не совсем так. В моём случае предполагается разработка разнообразных новых продуктов. Я совершенно согласен что проектный подход в данном случае совершенно не нужен. Но это же типичная ситуация для многих компаний. И тогда возникает вопрос — а зачем нужен проектный подход или проектная деятельность? Откуда эти восторги про новое слово в разработке?
Опять же — это просто общие слова, за которыми ничего нет.
Вот давайте ещё раз рассмотрим вашу задачу:
В начале выполнения проекта аналитик Петр с точностью до секунды уложился в сроки подготовки материалов для своих коллег программистов, постановки были выверены и согласованы с клиентом, спецификации для разработки были отточены до «11 знаков после запятой».
Т.е. всё самое важное — сделал Пётр. По контексту видно что он не советовался с программистами и руководителем.
Что делал Иван в это время? Подходил и спрашивал «как дела ?»
Тогда попытайтесь сформулировать что он делает, но пожалуйста без отсылки к стандартам. Там слишком много воды.
И давайте уточним его квалификацию, что он вообще может делать.
Это общие слова. Можно также сказать что именно поэтому ракеты падают и ряд уникальных проектов не появился на рынке.
У вас пример из области программирования. Вот простой пример который не укладывается в иерархию. Вводим допущение, что в компании, где работает Иван, Вячеслав и другие разработчики, в течении долгого времени разрабатывается какая то библиотека. На основе этой библиотеки делаются разные проекты для разных заказчиков. Библиотека развивается, каждый новый проект для заказчика вносит что то новое. Или улучшает старое. Команда программистов бережно относиться к этой библиотеке, её развивает, холит и лелеет.
В результате описать ВСЕ работы компании в виде иерархии не получается. В рамках проектного управления будет отдельный проект для библиотеки, отдельные проекты для каждого из заказчиков. Но это уже искусственное ограничение. Эти работы могут быть описаны в рамках сетевой модели, и это будет органично.
На мой взгляд иерархия не может правильно описать структуру работ. И от этого пойдут все остальные проблемы. Которые конечно есть и в остальных ведущих проектных институтах.
Я знаю про проектное управление. В вашем случае получается что Иван занимается только руководством проектом. Т.е. берёт ответственность, заполняет планы. На мой взгляд, он получает неоправданно много. Нормальный уровень оплаты — около 20.
Описана классическая схема управления проектом. Сразу возникает вопрос — а в чём отлчие от других?
Проблемы здесь точно такие же.
Во первых представляется крайне сомнительным что можно заранее расписать все задачи и определить из трудоёмкость. Это можно сделать только для очень простых проектов.
Во вторых также крайне сомнительна возможность создать иерархию задач. Обычно иерархия недостаточно точно описывает систему.
Ну и про Ивана — отпуск это святое, конечно он может уйти.
Вот мне совершенно не нравиться «идеологически правильный» код передатчика. Как уже писали выше это потенциальный источник ошибок. На мой взгляд лучше использовать конструкцию always (@postedge clk) и внутри описывать нужную логику.
Это кстати то что PMBoK сразу отвергает, утверждая что это неэффективная структура но не приводя убедительных доказательств.
Полностью видеть проект может только тот кто обладает квалификацией, разруливать конфликты — человек с авторитетом, который ещё надо заработать. Собрать зоопарк вместе — это вообще высшая квалификация, руководителям она обычно не доступна. Хотя бы потому что когда человек начинает руководить и перестаёт работать руками то квалификация теряется.
Так что проектный подход это просто модный термин. За ним стоит только одно — это система распределения денег. Собственно именно это является основным в PMBoK. Остальное — дымовая завеса. Где-то в какой то компании это сработало. Видимо в результате случайностей кто-то из авторитетных руководителей придумал схему и модный термин. У них получилось. А дальше просто образовался карго-культ. Вот давайте сделаем такие же названия и оно само образуется. И ещё метрики введём. И чем более непонятны метрики тем лучше.
Так что позвольте вам не поверить про наиболее эффективный подход. Проектный подход как то работает, он создаёт иллюзию контроля. Но считать его панацеей и серебрянной пулей как то странно.
То что вы написали про руководителя проекта это конечно классическое определение. Но оно ещё как то может быть оправдано для больших проектов. Но не для проекта в котором задействовано четыре человека.
Я не зря спросил про квалификацию Ивана. Давайте всё таки выясним что он может делать. Основные вопросы:
1. Он является специалистом в предметной области?
2. Он является программистом?
3. Он работал вместе с Петром над спецификациями? Т.е. он вообще знает что в проекте твориться?
Пока из ваших ответов я понял что он занимается общим руководством, для меня это означает что он является совершенно бесполезным человеком в этом проекте. Из этого вытекает следствие, что самое лучшее что он может сделать это уехать в отпуск. Это нужно что бы не мешаться под ногами у программистов в самый ответственный момент.
Вот давайте ещё раз рассмотрим вашу задачу:
Т.е. всё самое важное — сделал Пётр. По контексту видно что он не советовался с программистами и руководителем.
Что делал Иван в это время? Подходил и спрашивал «как дела ?»
И давайте уточним его квалификацию, что он вообще может делать.
У вас пример из области программирования. Вот простой пример который не укладывается в иерархию. Вводим допущение, что в компании, где работает Иван, Вячеслав и другие разработчики, в течении долгого времени разрабатывается какая то библиотека. На основе этой библиотеки делаются разные проекты для разных заказчиков. Библиотека развивается, каждый новый проект для заказчика вносит что то новое. Или улучшает старое. Команда программистов бережно относиться к этой библиотеке, её развивает, холит и лелеет.
В результате описать ВСЕ работы компании в виде иерархии не получается. В рамках проектного управления будет отдельный проект для библиотеки, отдельные проекты для каждого из заказчиков. Но это уже искусственное ограничение. Эти работы могут быть описаны в рамках сетевой модели, и это будет органично.
Он что-то полезное делает?
Или только руководит?
Описана классическая схема управления проектом. Сразу возникает вопрос — а в чём отлчие от других?
Проблемы здесь точно такие же.
Во первых представляется крайне сомнительным что можно заранее расписать все задачи и определить из трудоёмкость. Это можно сделать только для очень простых проектов.
Во вторых также крайне сомнительна возможность создать иерархию задач. Обычно иерархия недостаточно точно описывает систему.
Ну и про Ивана — отпуск это святое, конечно он может уйти.
В VHDL повторное присваивание внутри процесса (аналог always) прекрасно работает. Выполняться будет последнее по тексту.