2.
Isar
21.05.20 21:09
Сейчас в теме
1. Начинается всё с того, что заказчик пишет ТЗ-"залипуху", т.е. бумажку, которой грош-цена. В этой ТЗ удается, в лучшем случае, сформулировать цель - зачем нужно что-то сделать. Так как цель понятна всем сторонам, все соглашаются с этой "залипухой" и отдают в работу разработчику.
2. Таких "залипух" у разработчика, как правило, лежит немало. Выстраивается очередь. Нормирование работ по таким ТЗ всегда ошибочно, чаще всего ошибки из-за чрезмерно оптимистичной оценки, которые приводят впоследствии к срыву сроков. И поэтому очередь не уменьшается, а увеличивается.
3. Разработчик берется за работу по "залипухе" и начинает погружаться в задачу. По сути, именно в этот момент и происходит первое серьезное осмысление того, что нужно сделать, какими средствами и способами. Разработчик узнает много новых, доселе неведомых деталей. Когда он обращается к заказчику, то сталкивается с непониманием и недоумением, поэтому чаще всего самостоятельно выбирает и принимает проектные решения, как в мелочах, так и в крупных и принципиальных вопросах. Работа обрастает нюансами, некоторые из них согласовываются с заказчиком, но не все. Проявляются все ошибки нормирования и оценки. Но уже поздно что-то менять.
4. Разработчик передает очередного "монстра Франкенштейна", созданного в соответствии с "залипухой". Так как "залипуха" была больше похоже на детский рисунок, чем на рабочий проект, результат может довольно сильно отличаться от "залипухи". Как реальный автомобиль сильно отличается от нарисованного мальчиком. Начинается тестирование, точнее проверка. Заказчик по наитию пробует работоспособность доработки и принимает, очень часто ошибочное, решение о принятие работ. Тем более, что заказчик уже давно температурит. Тестирование завершено.
5. Творение Франкенштейна поступило в распоряжение заказчика. Мы настаиваем на подписании актов. Времени на проверку работ немного, а сроки сорваны. Заказчик раздражён, принимать быстро не хочет. За 3-5 дней заказчик не в состоянии собрать все замечания не протестированной должным образом работы. Ошибки лезут, исправляются, а скорее просто латаются. Акты со скрипом подписаны.
6. По уже сданной работе начинается болезненный процесс гарантии. Вся эта гарантия ложится на плечи того же разработчика (а кого же еще), ведь это он создал этого монстра Франкенштейна. Идут непроизводительные затраты времени, а значит и денег. Срываются сроки выполнения текущих задач. Заказчик раздражен еще больше. Заказчик не хочет платить и угрожает разорвать отношения.
7. Итоги: огромное количество непродуктивного использования рабочего времени (разговоры, гарантия); недовольный заказчик; низкие доходы за работу и, следовательно, низкие зарплаты.