Комментарии 19
Можно использовать систему SCM — систему контроля изменений. Она подразумевает такую методику, что любая даже самая незначительная идея или изменение записывается в багтрак, просто на будущее. Затем когда руки доходят до изменений можно пачкой просмотреть все предложенные изменения и сделать выводы что с ними делать. Если вы успеваете по проекту и время есть, можно что-то да и сделать. Если не успеваете, то идеи просто откидываются и будут имплементится отдельно.
Каждое изменение может рассматривать какой то комитет по изменениям (это быть может и один человек который решает жестко — быть или не быть), выставляет ему статус и приоритет исполнения.
В принципе практически тоже самое что и у вас. Только Вы до этого дошли сами, а то что я рассказал было описано уже давным давно. рекомендую вам почитать МакКонела Совершенный код. Там это все есть.
Каждое изменение может рассматривать какой то комитет по изменениям (это быть может и один человек который решает жестко — быть или не быть), выставляет ему статус и приоритет исполнения.
В принципе практически тоже самое что и у вас. Только Вы до этого дошли сами, а то что я рассказал было описано уже давным давно. рекомендую вам почитать МакКонела Совершенный код. Там это все есть.
Лучше «Разработка требований к программному обеспечению», Карл Вигерс. А так же взглянуть на методологию Scrum, как там решается этот вопрос.
Все зависит от величины пректа, если надо добавить счетчик на пятистраничный сайт, то ради этого просто неохота влазить в бумажную бухгалтерскую волокиту. Если клиент просит: «А вот почему у меня такой штучки нет, у моих конкурентов она есть? Я вам столько денег заплатил — хочу!!!», — а вот эта штучка требует концептуально другую компановку CMS, — то здесь остается прикрываться только ТЗ. Мы в работе с клиентами всегда обговариваем «7 пункт» и его последствия для обоих сторон.
Обязательно посмотрю, спасибо.
НЛО прилетело и опубликовало эту надпись здесь
мне кажется, что завысив цену и объявив об этом, и о полной готовности к любым доработкам и быть папой и мамой до определенного момента проще всего. Потому-что в большинстве случаев мы работаем с людьми, которые не понимают больше половины слов произнесенными нами. Ведь задрачивает на шару рассказывать элементарное по 10 раз в день. А тут все довольны…
А почему бы просто не записать все идеи и через некоторое время предложить заказчику как обновление?
Я с такой же проблемой сейчас столкнулся. Разница в том, что проект делаю для себя. В процессе возникает куча идей, которые стоят времени, потому просто записываю их в тетрадку с набросками (я дизайнер), а в основном проекте просто беру это на заметку. Как будет готова основа, возьму более привлекательную заметку и буду ее реализовывать.
Я с такой же проблемой сейчас столкнулся. Разница в том, что проект делаю для себя. В процессе возникает куча идей, которые стоят времени, потому просто записываю их в тетрадку с набросками (я дизайнер), а в основном проекте просто беру это на заметку. Как будет готова основа, возьму более привлекательную заметку и буду ее реализовывать.
НЛО прилетело и опубликовало эту надпись здесь
Я таким способом поддерживаю отношения с заказчиками. Сделал проект, через 2-3 месяца связался, предложил ту идею или идеи, что придумал еще при разработке.
Сразу предлагать не стоит, со стороны это выглядит как «хочу больше денег».
Сразу предлагать не стоит, со стороны это выглядит как «хочу больше денег».
Я так делаю, только в сфере разработки клиент-серверного софта.
Все требования к прототипу и набросок базы реализуется в версии 1.0, потом идут итерации, каждая итерация задокументирована на 2-3 шага вперёд, заказчик имеет к ним доступ и при желании вносит свои предложения (именно предложения а не коррективы). Если нужны изменения в БД то меняем Minor версию и в прогу зашивается апдейтер БД с предыдущей версии. Если изменения только в клиенте — делаем новый Release. И как показывает практика, то что озвучено в ТЗ мы получаем в версии 1.0.5-1.1.5, а то что хочет заказчик, обычно не ранее 1.5.3. Так заказчик видит весь процесс, знает за что платит, и сам решает когда можно ещё добавить фич, а когда остановиться.
И да: есть три очереди на исполнение Bugtrack, ToDo и Wishes — в порядке убывания важности.
Все требования к прототипу и набросок базы реализуется в версии 1.0, потом идут итерации, каждая итерация задокументирована на 2-3 шага вперёд, заказчик имеет к ним доступ и при желании вносит свои предложения (именно предложения а не коррективы). Если нужны изменения в БД то меняем Minor версию и в прогу зашивается апдейтер БД с предыдущей версии. Если изменения только в клиенте — делаем новый Release. И как показывает практика, то что озвучено в ТЗ мы получаем в версии 1.0.5-1.1.5, а то что хочет заказчик, обычно не ранее 1.5.3. Так заказчик видит весь процесс, знает за что платит, и сам решает когда можно ещё добавить фич, а когда остановиться.
И да: есть три очереди на исполнение Bugtrack, ToDo и Wishes — в порядке убывания важности.
Когда проект разрабатывается «для себя» работают немного другие мотивы. Но даже в таком случае, лично я стараюсь придерживаться начального плана, а реализацию идей откладываю на некоторое время.., чтоб взглянуть на них чуть позже более свежим взглядом.
Простите, не могу спокойно смотреть на главную страницу…
Предлагайте бюджет в 1,5-2 раза больше предполагаемых затрат человекочасов. И тогда он в точности покроет затраченные на него силы по завершению.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что делать с полезными идеями, которые мешают работать?