Процессы в ИТ: Долго, дорого и не то
Многие привыкли к треугольнику Хопкинса (Быстро, Дёшево, Качественно), он же - треугольник ограничения проектов. Вместе с тем в бизнесе популярным стало: «Ох уж эти программисты: опять долго, дорого и не то».
Многие привыкли к треугольнику Хопкинса (Быстро, Дёшево, Качественно), он же - треугольник ограничения проектов. Вместе с тем в бизнесе популярным стало: «Ох уж эти программисты: опять долго, дорого и не то».
В статье подмена понятий.
Очевидно, что чем больше качество работы конкретных сотрудников, тем лучше. Не имеет никакого смысла снижать качество конкретных работ.
Но при этом, треугольник качество-сроки-бюджет на уровне проекта вполне имеет место, и этим надо управлять.
В IT низкое качество это может значить, что мы не фиксим некоторые не самые важные баги, не оптимизируем время выполнения части операций программы, ревью UI делается 1 итерация вместо 3х, и т.д.
Низкое качество - это дополнительные операции. В том числе и операции контроля. Например вы говорите о ревью UI, причем говорите о целых 3 итерациях. Это время и деньги.
А почему возникла необходимость в этом ревью? Кто что недоделал и кто что переложил на коллег?