Comments 3
Очень понравился как стиль изложения, так и описанные процессы — видно, что они эволюционировали под влиянием реального опыта.
Есть несколько недостатков, связанных с децентрализацией:
1.Управление продуктом — заказчик может заказать доработку того, что или будет и так в новой версии, или то, что будет заменено другим функционалом.
2.Управление ресурсами — заказчик может из раза в раз одного и того же исполнителя аллокировать, это приведет к неравномерной загрузке всех исполнителей и невозможности планирования, например, отпуска.
3.Управление портфелем заявок — может сложиться ситуация, когда заявок много, ресурсов мало и кто-то должен волевым решением их переприоритезировать.
4.Субъективизм — указание квалификации разработчика фиксируется до оценки сложности задачи исполнителем.
1.Управление продуктом — заказчик может заказать доработку того, что или будет и так в новой версии, или то, что будет заменено другим функционалом.
2.Управление ресурсами — заказчик может из раза в раз одного и того же исполнителя аллокировать, это приведет к неравномерной загрузке всех исполнителей и невозможности планирования, например, отпуска.
3.Управление портфелем заявок — может сложиться ситуация, когда заявок много, ресурсов мало и кто-то должен волевым решением их переприоритезировать.
4.Субъективизм — указание квалификации разработчика фиксируется до оценки сложности задачи исполнителем.
Отвечаю по пунктам:
1. заказчик может заказать доработку того, что или будет и так в новой версии, или то, что будет заменено другим функционалом.
Решение, работающее у заказчика — монолитное, и выход новой версии базовой конфигурации никак не влияет на решение у клиента. За подробностями позволю себе привести ссылки на мои предыдущие статьи Буриданов осел и композиция конфигурации и еще про модули. Коротко — функционал заказчику нужен потому, что есть бизнеспотребность. А она не привязана к новым версиям и тому подобному.
2. заказчик может из раза в раз одного и того же исполнителя аллокировать, это приведет к неравномерной загрузке всех исполнителей и невозможности планирования, например, отпуска.
Теоретически — да. Однако такого на практике не происходит. Тут я вижу 2 фактора:
— Разработчики отличаются не сильно (по крайней мере при сравнимых грейдах)
— Даже если такая звезда появляется, его личная ставка поднимается, и спрос на него падает по законам рынка.
3. Может сложиться ситуация, когда заявок много, ресурсов мало и кто-то должен волевым решением их переприоритезировать.
Это ошибка. Кто-то должен решить как найти ресурсы. Для переприоритизации есть только механизм приоритетов. Иначе начнется хаос, который продолжится и после пика нагрузки. Отучить заказчика от этого «удобного» механизма будет невозможно.
4.Указание квалификации разработчика фиксируется до оценки сложности задачи исполнителем.
Как указано в статье — заказчик может указать желаемую квалификацию. Может не указывать. Либо я не понял что-то.
1. заказчик может заказать доработку того, что или будет и так в новой версии, или то, что будет заменено другим функционалом.
Решение, работающее у заказчика — монолитное, и выход новой версии базовой конфигурации никак не влияет на решение у клиента. За подробностями позволю себе привести ссылки на мои предыдущие статьи Буриданов осел и композиция конфигурации и еще про модули. Коротко — функционал заказчику нужен потому, что есть бизнеспотребность. А она не привязана к новым версиям и тому подобному.
2. заказчик может из раза в раз одного и того же исполнителя аллокировать, это приведет к неравномерной загрузке всех исполнителей и невозможности планирования, например, отпуска.
Теоретически — да. Однако такого на практике не происходит. Тут я вижу 2 фактора:
— Разработчики отличаются не сильно (по крайней мере при сравнимых грейдах)
— Даже если такая звезда появляется, его личная ставка поднимается, и спрос на него падает по законам рынка.
3. Может сложиться ситуация, когда заявок много, ресурсов мало и кто-то должен волевым решением их переприоритезировать.
Это ошибка. Кто-то должен решить как найти ресурсы. Для переприоритизации есть только механизм приоритетов. Иначе начнется хаос, который продолжится и после пика нагрузки. Отучить заказчика от этого «удобного» механизма будет невозможно.
4.Указание квалификации разработчика фиксируется до оценки сложности задачи исполнителем.
Как указано в статье — заказчик может указать желаемую квалификацию. Может не указывать. Либо я не понял что-то.
Sign up to leave a comment.
Тайны мадридского двора Или устройство основных бизнес-процессов компании Ultima. Часть 1