Р
Простой членов команды не является проблемой, если при этом продвижение по проекту идёт с нужной скоростью.
Человек не реализующий себя теряет вовлеченность, если ценность проект вопросов нет, не везде так
Size: a a a
2019 November 14
VA
Откуда там упущенная выгода?
Простой разраба
VA
Зарплата есть, работы нет
AS
Тут есть вполне понятное противоречие. Универсала легче планировать, но он менее эффективен чем специалист и решает более простые задачи. Если проекты простые, то универсализация полезна. Если сложные - то вредна
А какой критерий сложности? И не является ли архитектура средством противодействия увеличению сложности?
AP
А какой критерий сложности? И не является ли архитектура средством противодействия увеличению сложности?
тогда бы картинки tobe всегда выглядели как "выключаем сервера и по домам"
ES
Спорно. Упущенная выгода же
Если все члены команды загружены, то теряется гибкость организации в целом - нет возможности быстро среагировать на изменившиеся внешние условия, форсмажоры
AS
тогда бы картинки tobe всегда выглядели как "выключаем сервера и по домам"
Тогда бы, это когда?
PD
Человек не реализующий себя теряет вовлеченность, если ценность проект вопросов нет, не везде так
Наличие работы в рамках проекта и реализация себя - не связанные вещи. Если не задач в рамках проекта, то пусть petproject пилит. Да всегда есть чем заняться.
AP
Тогда бы, это когда?
если бы архитектура всегда (или только) являлась средством противодействия увеличению сложности
AS
PD
Зарплата есть, работы нет
Нет, это не так. Его компетенции нужны в проекте и входят в его себестоимость. Ты покупаешь компетенции, а не человека
VA
Eugene Savin
Если все члены команды загружены, то теряется гибкость организации в целом - нет возможности быстро среагировать на изменившиеся внешние условия, форсмажоры
это задачи управленцев реагировать, а не разработчиков, имхо
AS
Просто есть декомпозиция сложности. В рамках единицы декомпозиции (продукта) люди должны быть универсальны
PD
А какой критерий сложности? И не является ли архитектура средством противодействия увеличению сложности?
И архитектура тоже, конечно. Но бывает и сложность предметной области, не только самого решения. И орг.сложности.
VA
Нет, это не так. Его компетенции нужны в проекте и входят в его себестоимость. Ты покупаешь компетенции, а не человека
но в итоге нужны продукты, ибо за них платят, так что если плохо настроил работу, то либо продукт дорого продал и имеешь люфт, либо начинаешь считать убытки
PD
Просто есть декомпозиция сложности. В рамках единицы декомпозиции (продукта) люди должны быть универсальны
Кому должны?
AP
Про убытки от простоя и вовлечённость - тут нет точки спора. Если компания продаёт тупо человекочасы (простите, разрабатывает проекты), тогда одно утверждение верно. Если компания создаёт продукт - другое.
В первом случае выгодно загружать людей работой и плевать на мотивацию. Во втором - скорее наоборот
В первом случае выгодно загружать людей работой и плевать на мотивацию. Во втором - скорее наоборот
AS
Кому должны?
Это более эффективно. Нет bus factor, взаимозаменяемость, шаринг знаний.
ES
это задачи управленцев реагировать, а не разработчиков, имхо
так мы про управление и говорим. Тут все сказанное - не зона ответственности команды разработки (DEV, QA, ...)
VA
Eugene Savin
так мы про управление и говорим. Тут все сказанное - не зона ответственности команды разработки (DEV, QA, ...)
Я имел ввиду, что разработчик должен всегда иметь что делать, кроме тех часов, которые ему "дарят" бонусом для саморазвития/петпроектов/проч