Что делать с полезными идеями, которые мешают работать?

    Работа над большими, серьезными или нестандартными проектами в большинстве случаев требует особого подхода, завидной прилежности, не дюжего терпения и крепкой психики. Я могу сказать, что владельцы небольших студий трезво оценивающие свои ресурсы, часто отказываются от подобных предложений по целому ряду причин.

    На мой взгляд, основная состоит в том, что для нас (небольших разработчиков) это очень «длинные деньги». Как бы подробно менеджеры не документировали все в техническом задании, в реальной разработке такой проект быстро обрастает балластом из различных предложений, усовершенствований, доделок, не учтенных сложностей, плохой обратной связи, новых идей, мыслей и т.д., которые возникают практически на всех этапах разработки.

    Вроде бы все это мелочи, которых в отдельности не видно, и как-то не серьезно требовать за них доплату. Так как этих мелочей в процессе накапливается очень много, их реализация приводит либо к значительному увеличению сроков, либо к дополнительной нагрузке на коллектив разработчиков.

    Частично проблему решает, очень подробное т.з. но его пишут тоже люди и как показывает практика всего учесть — все равно не возможно. Поэтому следующим нашим шагом было разбиение проекта на логически завершенные части, каждая из которых оплачивается по факту сдачи. К примеру выделяем:

    1. Дизайн, верстку
    2. Сборку сайта
    3. Наполнение проекта.
    4. Управление пользователями
    5. Интерактив. Форумы, комментарии, уведомления, внутренняя почта
    6. Билинг и т.д.

    Количество и объем частей определяется на усмотрение рабочей группы. В этом нет ничего нового и революционного, я думаю так или почти также, поступает большинство. Потому что разбиение превращает «длинные деньги» в более менее «быстрые», но не решает основной проблемы с идеями, дополнениям и прочим «балластом».

    С недавнего времени в список основных этапов, мы в обязательном порядке (последним пунктом) включаем «Доводку» иногда объединяя ее с проверкой и первичным тестированием. Причем в денежном отношении доводка не дешевле остальных этапов!

    Такой простой подход, позволяет сохранить душевное равновесие всему коллективу и заказчику… Мы спокойно делаем проект переходя от одной части к другой, трепетно записывая все пожелания и идеи заказчиков, да и свои собственные в отдельный файлик.

    К моменту, когда реализован предпоследний пункт в списке, мы получаем рабочую альфу. Но самое главное:
    • Замечательную возможность оценить реальную пользу идей-дополнений из нашего списка с точки зрения цельного проекта.
    • Именно когда основная работа над проектом завершена, становится очевидно что некоторые мысли были предложены «с горяча» и в их реализации просто нет необходимости и большого смысла.
    • Заказчику становится видно сколько томов занимают его «мелочи» :)
    Я не настаиваю на авторстве подобного подхода, возможно кто-то об этом уже писал… Мы к этому пришли самостоятельно, набив не одну шишку :) Поэтому буду очень рад если наш опыт окажется для кого-то полезным.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 19

      +6
      Можно использовать систему SCM — систему контроля изменений. Она подразумевает такую методику, что любая даже самая незначительная идея или изменение записывается в багтрак, просто на будущее. Затем когда руки доходят до изменений можно пачкой просмотреть все предложенные изменения и сделать выводы что с ними делать. Если вы успеваете по проекту и время есть, можно что-то да и сделать. Если не успеваете, то идеи просто откидываются и будут имплементится отдельно.

      Каждое изменение может рассматривать какой то комитет по изменениям (это быть может и один человек который решает жестко — быть или не быть), выставляет ему статус и приоритет исполнения.

      В принципе практически тоже самое что и у вас. Только Вы до этого дошли сами, а то что я рассказал было описано уже давным давно. рекомендую вам почитать МакКонела Совершенный код. Там это все есть.
        +1
        Лучше «Разработка требований к программному обеспечению», Карл Вигерс. А так же взглянуть на методологию Scrum, как там решается этот вопрос.
          0
          Все зависит от величины пректа, если надо добавить счетчик на пятистраничный сайт, то ради этого просто неохота влазить в бумажную бухгалтерскую волокиту. Если клиент просит: «А вот почему у меня такой штучки нет, у моих конкурентов она есть? Я вам столько денег заплатил — хочу!!!», — а вот эта штучка требует концептуально другую компановку CMS, — то здесь остается прикрываться только ТЗ. Мы в работе с клиентами всегда обговариваем «7 пункт» и его последствия для обоих сторон.
          0
          Обязательно посмотрю, спасибо.
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              мне кажется, что завысив цену и объявив об этом, и о полной готовности к любым доработкам и быть папой и мамой до определенного момента проще всего. Потому-что в большинстве случаев мы работаем с людьми, которые не понимают больше половины слов произнесенными нами. Ведь задрачивает на шару рассказывать элементарное по 10 раз в день. А тут все довольны…
              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  об том и речь стать мамой и папой для таких
                +2
                А почему бы просто не записать все идеи и через некоторое время предложить заказчику как обновление?

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

                        0
                        Да уж, это из серии «нарочно не придумаешь» :)
                          0
                          уже dirty напоминает с его гертрудами к посту
                          0
                          Предлагайте бюджет в 1,5-2 раза больше предполагаемых затрат человекочасов. И тогда он в точности покроет затраченные на него силы по завершению.
                          • НЛО прилетело и опубликовало эту надпись здесь

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое