В мифологичности разработки по ТЗ уже убедился на собственном опыте. Однако так и не решил для себя проблему оценки стоимости проекта если работать в коротких итерациях. Если в ТЗ зафиксировано конечное состояние системы, то понятно сколько будет стоить достигнуть данного состояния. Да и Заказчик просит назвать конкретную сумму. Однако при итерационной разработке конечное состояние разработки задается не так явно. И как же оценить проект до его начала? Как такое вообще в контракте то написать? Примеры искал - не нашел. Может есть какие-то мысли у местного знающего сообщества?
С удовольствием прочел.
Сам руковожу командой постановщиков и программистов. Пишем и внедряем на платформе 1С. Одно из решений, которое я попробовал - это общая зависимость от конечного результата. Т.е. премию получает команда за командный результат. А не так что, постановщик вовремя подписал и сдал ТЗ, которое вовремя оплатили и получил премию, а кодировщики замучились писать по этому ТЗ. В сущности это простое утверждение командного результата на уровне денежной компенсации. Вся команда сидит в одной лодке и если каждый будет грести как ему вздумается, мы никогда не приплывем туда, куда хотим приплыть. К сожалению в веб разработках не участвуем, но вот у нас постановщики очень часто консультируются с кодировщиками на предмет как лучше организовать тот или иной документ. Просто взгляд с разных точек зрения на один предмет. С моей точки зрения это подчас выглядит как постоянная болтовня. :-) Но результат есть. Просто надо видимо свести это к нормальным формальным митингам. Но это уже к данной теме не относится.
Переделав кучу заданий как во фрилансе, так и вне его утвердился в нескольких вещах
1. ТЗ надо делать самому. И брать за это деньги.
2. Прописать все ньюансы в договоре. Если невозможно все прописать - задирать сумму повыше
3. Дробить работу на этапы. Закрыли очередной этап: подписали акт и оплатили денежку, вот тогда начинаем следующий.
4. Если уже на первой встрече (никакого ТЗ нет и в помине) Заказчик требует назвать хоть примерный бюджет, то пользуюсь правилом - всплывающую в мозгу цифру (что уже всплыло после озвучивания всех требований вперемешку) умножить на 2, прибавить НДС и сообщить Клиенту.
5. Пословица "Ничто так не укрепляет веру в человека как 100% предоплата" при несоблюдении пунктов 1 - 4 позволяет Заказчику никогда не принять проект, требуя бесконечнеых бесплатных доделок.
Резюме: Каждый берет свою часть ответсвенности на себя. И как ни странно подчас для Клиентов это слышать - у них есть ответственность не только в финансовом плане.
Сам руковожу командой постановщиков и программистов. Пишем и внедряем на платформе 1С. Одно из решений, которое я попробовал - это общая зависимость от конечного результата. Т.е. премию получает команда за командный результат. А не так что, постановщик вовремя подписал и сдал ТЗ, которое вовремя оплатили и получил премию, а кодировщики замучились писать по этому ТЗ. В сущности это простое утверждение командного результата на уровне денежной компенсации. Вся команда сидит в одной лодке и если каждый будет грести как ему вздумается, мы никогда не приплывем туда, куда хотим приплыть. К сожалению в веб разработках не участвуем, но вот у нас постановщики очень часто консультируются с кодировщиками на предмет как лучше организовать тот или иной документ. Просто взгляд с разных точек зрения на один предмет. С моей точки зрения это подчас выглядит как постоянная болтовня. :-) Но результат есть. Просто надо видимо свести это к нормальным формальным митингам. Но это уже к данной теме не относится.
1. ТЗ надо делать самому. И брать за это деньги.
2. Прописать все ньюансы в договоре. Если невозможно все прописать - задирать сумму повыше
3. Дробить работу на этапы. Закрыли очередной этап: подписали акт и оплатили денежку, вот тогда начинаем следующий.
4. Если уже на первой встрече (никакого ТЗ нет и в помине) Заказчик требует назвать хоть примерный бюджет, то пользуюсь правилом - всплывающую в мозгу цифру (что уже всплыло после озвучивания всех требований вперемешку) умножить на 2, прибавить НДС и сообщить Клиенту.
5. Пословица "Ничто так не укрепляет веру в человека как 100% предоплата" при несоблюдении пунктов 1 - 4 позволяет Заказчику никогда не принять проект, требуя бесконечнеых бесплатных доделок.
Резюме: Каждый берет свою часть ответсвенности на себя. И как ни странно подчас для Клиентов это слышать - у них есть ответственность не только в финансовом плане.