Комментарии 91
Сколько контактных представителей заказчика вы готовы иметь?
одного. остальных надо отдельно вносить в бюджет и сроки, т.к. обязательно будут противоречия, которые прийдется решать исполнителю, а не руководителю проекта со стороны заказчика.
конечно лучше иметь одного адекватного, внимательно Вас слушающего и четко выдающего требования представителя заказчика.
желательно, также, чтобы он сразу присылал самое подробное ТЗ, в котором бы не было никаких противоречий.
желательно, также, чтобы он сразу присылал самое подробное ТЗ, в котором бы не было никаких противоречий.
А чего столько иронии? У нас получается иметь _одно_ контактное лицо для общения с Заказчиком.
у меня тоже получается в 90% случаев. но что делать в случае оставшихся 10% тоже нужно знать.
в конце концов люди могут уволиться, могут быть уволены или банально заболеть надолго.
в конце концов люди могут уволиться, могут быть уволены или банально заболеть надолго.
По моей практике, очень нередки случаи, когда такое лицо вдруг уходит в отпуск, а руководство заказчика назначает на это время другое лицо, мол, чтобы работа не останавливалась. Тут начинается самое весёлое. Новое лицо долго "въезжает", а потом ему не нравится всё то, что нравилось первому лицу.
один заказчик не утопия, этого можно добиться.
самое подробное ТЗ, по крайней мере для проектов в которых я участвовал, все-таки утопия.
самое подробное ТЗ, по крайней мере для проектов в которых я участвовал, все-таки утопия.
«желательно, также, чтобы он сразу присылал самое подробное ТЗ, в котором бы не было никаких противоречий»
Это сродни сферическому коню в вакууме ;) Теоретически возможно, но на практике — нереально.
Это сродни сферическому коню в вакууме ;) Теоретически возможно, но на практике — нереально.
Хорошая статья.
офф.: "кучи нерВных клеток"
офф.: "кучи нерВных клеток"
Весь смысл можно уместить в "Ребята, согласовывайте все с заказчиком и удостоверьтесь, что вы делаете то, что нужно заказчику."
Я считаю, что если заказчик утвердил ТЗ, то его и нужно реализовывать. Любое изменение ТЗ есть отдельный заказ и должен оплачиваться отдельно.
Это более, чем утопическое заявление, особенно учитывая обычную проработку ТЗ в проектах.
Так как фраза Жука верна по своей сути, может она не такая уж утопическая и просто нужно подробнее прорабатывать ТЗ?
А я не против сути, я за понимание реалий :) И вы, действительно, за фразу "Любое изменение ТЗ"?
Конечно, это же уже CR а не Bugfix. Estimate > Do > Invoice :)
Не любое. Поменять рядом стоящие кнопки местами и т.п. - не вопрос. Однако добавление в подсистему платежей никому неизвестного и ничего не поддерживающего провайдера - это уже change request. На это отдельно подготавливается план, estimate и т.п. Это почти отдельный проект.
Не сталкивался ни с одним заказчиком, который в конце проекта хотел того-же, что и в начале. Как только новая функциональность становится доступной, заказчик лучше понимает что именно он хочет. Если контракт позволяет, то именно итеративный подход (согласовываем, делаем, поставляем и снова по кругу) с часто и рано поставляемыми результатами работает лучше всего. К концу проекта тот ТЗ, который вначале смотрелся здорово, просто устаревает. Так что это время, как правило, лучше потратить на прототип
Я бы сказал, стоит в случае, когда чувствуешь, закладывать в бюджет расходы на такие «незначительные» изменения. А дополнения уже реально выходящие за рамки финансовых соглашений проводить по дополнительным выплатам.
В начале проекта - поезд и ходит по рельсам а в конце - у него есть крылья и летает. Бывают и такие "незначительные изменения" :))
То, что закладывать в контракт надо, как именно доролнительные изменения оплачиваются - бесспорно. Я лишь хотел сказать, что дает лучший результат для самомого же заказчика.
Ну а контракт, и что в него нужно писать - наверное, отдельная тема.
То, что закладывать в контракт надо, как именно доролнительные изменения оплачиваются - бесспорно. Я лишь хотел сказать, что дает лучший результат для самомого же заказчика.
Ну а контракт, и что в него нужно писать - наверное, отдельная тема.
Мы сейчас в процессе перехода от каскадного стиля разработки к улитке. Песок сыпется из всех щелей, но результат виден невооружённым взглядом. :)
Проблема внимания заказчика хорошо прослеживается, но при новом стиле ведения дел справляться с этим легче.
А про устаревающее ТЗ - здорово подмечено, просто моя любимая мозоль, можно сказать.
Проблема внимания заказчика хорошо прослеживается, но при новом стиле ведения дел справляться с этим легче.
А про устаревающее ТЗ - здорово подмечено, просто моя любимая мозоль, можно сказать.
а если нет времени писать ТЗ? если нужно согласовывать "на лету"?
НЛО прилетело и опубликовало эту надпись здесь
Начало интригующее, концовка подкачала. Выводы банальные.
Моя практика показывает, что основное действо разварачивается когда менеджер сидит с заказчиком и обсуждает детально проект. Если на этом этапе менеджер не понял заказчика, то тут уже не поможет ни утверждённое ТЗ, ни макеты, ни прочие контактные представители.
Ага! Несколько представителей заказчика. Смешно! Каждый из них с высокой степенью вероятности будет тащить одеяло на себя.
Пока видел только одну гениальную вещь на эту тему, которая и говорит о том, что надо делать, а чего нет:
что хотел заказчик
что хотел заказчик
Все не так просто как описал автор.
Контроль проекта со стороны нескольких представителей заказчика влечет к уменьшению степени ответственности со стороны каждого из них. Работать нужно именно с одним человеком, но как правильно упоминает автор - работать на всех этапах, а не когда ему это удобно. Следует также отметить что этот "Один человек" не должен быть МЕГАБоссом (т.е. самим заказчиком) - это должен быть сотрудник его организации который будет выступать в роли переводчика между Заказчиком и Разработчиком.
В целом и общем же - идеальных схем нет. В некоторых случаях (При неадекватности заказчика и малой конечной прибыли) можно упираться в договор и говорить что дополнительный функционал только за дополнительное время и дополнительные деньги. В случаях же когда поставляется система с последующей оплатой доработок и сопровождения с вашей стороны - имеется смысл даже при доработках остановиться на первоначальной сумме - т.к. при установленной и работоспособной системе заказчик скорее будет готов отдавать большие деньги за доработку и сопровождение - нежели за смену системы (Т.е. идем по принципу рынка приставок - приставки дешевле себестоимости - а деньги на аксессуарах и играх).
Контроль проекта со стороны нескольких представителей заказчика влечет к уменьшению степени ответственности со стороны каждого из них. Работать нужно именно с одним человеком, но как правильно упоминает автор - работать на всех этапах, а не когда ему это удобно. Следует также отметить что этот "Один человек" не должен быть МЕГАБоссом (т.е. самим заказчиком) - это должен быть сотрудник его организации который будет выступать в роли переводчика между Заказчиком и Разработчиком.
В целом и общем же - идеальных схем нет. В некоторых случаях (При неадекватности заказчика и малой конечной прибыли) можно упираться в договор и говорить что дополнительный функционал только за дополнительное время и дополнительные деньги. В случаях же когда поставляется система с последующей оплатой доработок и сопровождения с вашей стороны - имеется смысл даже при доработках остановиться на первоначальной сумме - т.к. при установленной и работоспособной системе заказчик скорее будет готов отдавать большие деньги за доработку и сопровождение - нежели за смену системы (Т.е. идем по принципу рынка приставок - приставки дешевле себестоимости - а деньги на аксессуарах и играх).
Именно. Поэтому мы в договоре чётко прописываем это контактное лицо — посредника. От остальных представителей Заказчика, мы имеем права не принимать поправки и прочее.
мы много чего имеем право не делать. мы имеем право не делать дополнительных изменений, мы можем упираться в договор, в начальные требования, в согласованные макеты.
только всем же интересно взаимовыгодное сотрудничество. и в любых спорах нужно все-таки стараться идти на компромисс и показывать себя с лучшей стороны, особенно если будущая выгода от проектов заказчика предположительно больше чем стоимость решения локального конфликта.
я старался написать о том, как именно можно постараться минимизировать риск возникновения конфликтных ситуаций и на какие показатели возникновения этого риска обратить внимание
только всем же интересно взаимовыгодное сотрудничество. и в любых спорах нужно все-таки стараться идти на компромисс и показывать себя с лучшей стороны, особенно если будущая выгода от проектов заказчика предположительно больше чем стоимость решения локального конфликта.
я старался написать о том, как именно можно постараться минимизировать риск возникновения конфликтных ситуаций и на какие показатели возникновения этого риска обратить внимание
А кто говорит, что мы рогом упираемся. Вся деятельность с нашей стороны, как Исполнителя, призвана показать, что мы заинтересованы работать с этим, конкретным, Заказчиком, и, следовательно, ждем от него готовности вникать в ход процесса, оптимальным образом. Поэтому и объясняется, что одно контактное лицо, это не прихоть, а желание сделать сам проект наилучшим образом.
Все это хорошо. Но стелится дорожкой не каждый умеет. Для кого-то накал обстановки и приводит к решению в лучшую сторону, сокращает сроки торможения.
Если заметить, то человек лучше соображает и действует в обстановке повышенного адреналина в крови. (Многие получают адреналин в фазе dead-line, я не про этот метод).
С заказчиком я предпочитаю драться за каждое фе, и ломать карандаши настаивая на своем виденьи "этого блока в левом углу".
Так же я согласен, что надо идти на компромис или поступаться, но только тогда когда у тебя есть доля сомнения в том, что именно твой метод/взгляд тут не прав.
Если заметить, то человек лучше соображает и действует в обстановке повышенного адреналина в крови. (Многие получают адреналин в фазе dead-line, я не про этот метод).
С заказчиком я предпочитаю драться за каждое фе, и ломать карандаши настаивая на своем виденьи "этого блока в левом углу".
Так же я согласен, что надо идти на компромис или поступаться, но только тогда когда у тебя есть доля сомнения в том, что именно твой метод/взгляд тут не прав.
огромное спасибо за развернутый комментарий.
вы все правильно говорите, про "одного человека", только к сожалению, даже это не всегда возможно.
с человеком может что-то произойти, он может заболеть, отправится в командировку, заменить другого человека и оказаться в состоянии "нехватки времени" на проект или перепоручить ведение проекта другому человеку. всякое-же бывает.
вы все правильно говорите, про "одного человека", только к сожалению, даже это не всегда возможно.
с человеком может что-то произойти, он может заболеть, отправится в командировку, заменить другого человека и оказаться в состоянии "нехватки времени" на проект или перепоручить ведение проекта другому человеку. всякое-же бывает.
А вот в этих случаях уже надо мыслить не по шаблонам - в этом момент начинается ИСКУССТВО управления проектом, которое, к сожалению, описанию и систематизированию не поддается.
Хотя, как я говорил в предыдущем комментарии - "переводчик" должен работать в организации заказчика, а как следствие все его косяки (нехватка времени, отключенный телефон во время отпуска) могут быть со спокойной совестью предъявлены заказчику на уровне невыполнения им условий контракта (который естественно должен быть оформлен в нужном ключе с самого начала. Обычно пишется пункт - гарантированная возможность обсуждения деталей проекта с заказчиком в рабочее время (5/8) (5 дней в неделю по 8 часов)), ну и сноски там всякие - например "за исключением стихийных бедствий". Этот момент уже должны проработать юристы.
Хотя, как я говорил в предыдущем комментарии - "переводчик" должен работать в организации заказчика, а как следствие все его косяки (нехватка времени, отключенный телефон во время отпуска) могут быть со спокойной совестью предъявлены заказчику на уровне невыполнения им условий контракта (который естественно должен быть оформлен в нужном ключе с самого начала. Обычно пишется пункт - гарантированная возможность обсуждения деталей проекта с заказчиком в рабочее время (5/8) (5 дней в неделю по 8 часов)), ну и сноски там всякие - например "за исключением стихийных бедствий". Этот момент уже должны проработать юристы.
ну искусство систематизированию не поддается, но сборник-описание в виде success stories можно было бы сделать.
"переводчик" - это я так понимаю, менеджер проекта со стороны заказчика. конечно, в случае идеального проекта у Вас на руках должен быть четко составленный договор, обговоренные и утвержденные спецификации, замечательный контракт, к которому не придраться в суде.
только это не всегда зависит конкретно от менеджера проекта, а принимать решения чаще всего как раз приходится именно ему.
"переводчик" - это я так понимаю, менеджер проекта со стороны заказчика. конечно, в случае идеального проекта у Вас на руках должен быть четко составленный договор, обговоренные и утвержденные спецификации, замечательный контракт, к которому не придраться в суде.
только это не всегда зависит конкретно от менеджера проекта, а принимать решения чаще всего как раз приходится именно ему.
Более того, это может быть крупная корпорация типа Сбербанка, где буквально с каждой ступеньки есть свой взгляд на вещи. Это вообще отдельная тема - внедрение у клиента-мегакорпорации (был у меня опыт, в Сбербанке). Составление ТЗ - чистилище, 7 кругов (базовый клиент->его верхушка->...->головная контора в Москве). Правильно совместишь пожелания на всех уровнях (по личному опыту около 30% противоречит друг другу) - получишь рай, неправильно совместишь - получишь ад. Познаешь клиента на уровне интуиции - попадешь в нирвану.
Как же избежать этоЙ опасности?
Управление рисками - это их учёт, актуализация степени воздействия на проект и планирование/проведение мероприятий по уменьшению последствий.
Так, на будущее.
Так, на будущее.
Боюсь, каким бы действительно актуальным и адекватным предложение не было бы, проблемы "а давайте мы теперь все сделаем вооОООООоооот так" будут всплывать. Тут скорее все же, на мой взгляд, от клиента очень многое зависит.
не думаю, что это можно назвать "управлением рисков", а скорее, "правилами ведения клиета". То, что клиент не удосужился посмотреть предварительный эскиз - это не риск, а ситуация, которую можно избегать элементарным обсуждением макета, а не "нравиться/не нравиться".
Риском я бы назвал те ситуации, когда клиент сознательно вносит поправки и стоит на своем или когда подрядчик тянет сроки.
Риском я бы назвал те ситуации, когда клиент сознательно вносит поправки и стоит на своем или когда подрядчик тянет сроки.
Нарушение спецификация - один из самых главных рисков проекта, причем дискретный по своей натуре.
И если он случается - все идет под откос, он чаще не замедляет проект, а просто губит его. Казалось бы, если вы не можете договориться, можно собирать вещи, тыкать в ТЗ и уходить от клиента. Но чаще всего люди обязаны договориться и риск маскируют. Отвлекаются, забывают на время и так далее. Только чем позже это все всплывет тем все больше больше вероятность того, что Ваш проект потерпит полный крах.
И если он случается - все идет под откос, он чаще не замедляет проект, а просто губит его. Казалось бы, если вы не можете договориться, можно собирать вещи, тыкать в ТЗ и уходить от клиента. Но чаще всего люди обязаны договориться и риск маскируют. Отвлекаются, забывают на время и так далее. Только чем позже это все всплывет тем все больше больше вероятность того, что Ваш проект потерпит полный крах.
Об этом и речь. Если искать компромис и подстраиваться - все все-равно всплывет, поэтому лучше сразу резать на корню, т.к. клиент, которому идут на уступки капризов к этому привыкает.
Я бы это назвал управление ожиданиями (хотя несовпадение ожиданий - однозначно риск :)). На мой взгляд PM'у имеет смысл плавно, постепенно и постоянно готовить ключевых стейкхолдеров клиента к конечному результату и постоянно проверять обратную связь. А поняли-ли? А на контрольные вопросы как отвечают? и т.п. В этом случае полученный ими результат не будет сюрпризом и таким образом можно минимизировать тот самый риск несовпадения ожиданий.
Еще один tip насчет повышения внимания. Из моего опыта полезно в документы, типа ТЗ/спецификаций добавлять небольшой дисклеймер (большими буквами), что подписывая данный документ заказчик подтверждает, что он все прочитал, задал все вопросы, получил все ответы и согласен, что все изменения или дополнения к данному документу идут через процедуру управления изменениями со всеми вытекающими. Конечно удовлетвореность клиента проектом это гарантировать не может в том случае если он все-таки не понял, но опыт показывает, что практически ни один из клиентов мимо этой надписи просто так не проходит.. читают все-таки значит :)) Опять же, с юридической точки зрения (на самый худой конец) этот пункт опять же может подстраховать.
Еще один tip насчет повышения внимания. Из моего опыта полезно в документы, типа ТЗ/спецификаций добавлять небольшой дисклеймер (большими буквами), что подписывая данный документ заказчик подтверждает, что он все прочитал, задал все вопросы, получил все ответы и согласен, что все изменения или дополнения к данному документу идут через процедуру управления изменениями со всеми вытекающими. Конечно удовлетвореность клиента проектом это гарантировать не может в том случае если он все-таки не понял, но опыт показывает, что практически ни один из клиентов мимо этой надписи просто так не проходит.. читают все-таки значит :)) Опять же, с юридической точки зрения (на самый худой конец) этот пункт опять же может подстраховать.
Я на своем опыте понял, что чем меньше итерации, тем меньше риски возникновения недопониманий. Колбасить месяц прототип и потом показывать его заказчику считаю недопустимым. В идеале заказчик должен смотреть на продукт раз в 2-3 дня и сразу же говорить свои замечания.
А в разработку по ТЗ давно не верю, это какой то буржуйский миф :)
А в разработку по ТЗ давно не верю, это какой то буржуйский миф :)
согласен, итерации хорошо бы делать короче и оттачивать этот процесс чтобы всегда держать руку на пульсе. но просто есть переходы, допустим от чб макетов к отрисованным в цвете, когда может выясниться, что "нужно было совсем не это", "ну как же так вы нас не поняли" и "да, мы утверждали, но имели ввиду совсем другое!". поэтому кроме как показать заказчику, надо еще и удостовериться, что он все понял.
кстати, такой же переход есть допустим, от прототипа к внедрению в него бизнес логики, когда казалось бы все было обговорено и ТЗ заказчик читал и утвердил, а нужно ему было все равно немного не то
В мифологичности разработки по ТЗ уже убедился на собственном опыте. Однако так и не решил для себя проблему оценки стоимости проекта если работать в коротких итерациях. Если в ТЗ зафиксировано конечное состояние системы, то понятно сколько будет стоить достигнуть данного состояния. Да и Заказчик просит назвать конкретную сумму. Однако при итерационной разработке конечное состояние разработки задается не так явно. И как же оценить проект до его начала? Как такое вообще в контракте то написать? Примеры искал - не нашел. Может есть какие-то мысли у местного знающего сообщества?
Решение вполне очевидное: договариваться с заказчиком об оплате времени сотрудников. По факту того, сколько займет разработка требуемых ему функций. Конечно, для большинства клиентов это будет очень необычный подход, но попробуйте объяснить клиенту плюсы такой схемы на примере того дела, которым он занимается.
Это не выгодно заказчику, все непонятные моменты разработчик обязан уточнить перед началом работ
Смысл Agile как раз в том, что раз все моменты до начала работ уточнить не получается, то и не надо. Подробные (детализированные до клика) задачи сотрудникам и документация по проекту формируются в процессе разработки.
Понятно, что у заказчика предложение почасовой оплаты вызовет недоверие ("Вы будете тянуть разработку, чтобы получить больше денег"), но если проект большой, то можно объяснить заказчику, что agile-подход будет самым разумным.
Понятно, что у заказчика предложение почасовой оплаты вызовет недоверие ("Вы будете тянуть разработку, чтобы получить больше денег"), но если проект большой, то можно объяснить заказчику, что agile-подход будет самым разумным.
Если бы я был заказчиком, а достаточно часто им бываю, то не согласился бы
It's up to you.
На маленьких проектах действительно нет смысла использовать agile - подойдет и хорошее ТЗ с wireframe. Риски в такой ситуации будут в пределах 20%, что вполне приемлемо.
Но на больших проектах документация не спасает. И либо в проект закладываются риски в 100% и выше (что невыгодно заказчику), либо риски не закладываются, и для исполнителя проект получается убыточным.
На маленьких проектах действительно нет смысла использовать agile - подойдет и хорошее ТЗ с wireframe. Риски в такой ситуации будут в пределах 20%, что вполне приемлемо.
Но на больших проектах документация не спасает. И либо в проект закладываются риски в 100% и выше (что невыгодно заказчику), либо риски не закладываются, и для исполнителя проект получается убыточным.
абсолютно согласен. При большом проекте достаточно, если работать в атмосфере доверия и профессионализма, достаточно описать заказчику объемы от ... до ..., объяснить какие есть риски и как Вы собираетесь с ними бороться и откуда есть некоторая неопределенность.
тогда заказчик будет понимать, за что он платит и какие он может действия совершить для минимизации рисков со своей стороны. да и бюджетом можно по ходу гибче управлять.
а у нас везде пытаются навязать фиксированный бюджет, не понимая, что тогда исполнитель закладывает все возможные риски и переплата за проект может достигать достаточно больших значений.
тогда заказчик будет понимать, за что он платит и какие он может действия совершить для минимизации рисков со своей стороны. да и бюджетом можно по ходу гибче управлять.
а у нас везде пытаются навязать фиксированный бюджет, не понимая, что тогда исполнитель закладывает все возможные риски и переплата за проект может достигать достаточно больших значений.
Приведите примеры
примеры чего именно?
Примеры больших и маленьких проектов, любой большой проект можно разбить на несколько маленьких
1) не всякий большой проект можно разбить на малые - части проекта часто тесно связаны между собой
2) даже если большой проект разбивается на малые, то это ничего не дает. у малых проектов тоже есть риски в пределах 20%, сложите их - получите 80% и выше.
3) сейчас в работе проект с ~50 wireframes, 70 страницами ТЗ, пачкой use cases, html-прототипом проекта. это - большой проект (хотя бывают и больше). и весь этот объем документации при непосредственной разработке приходится менять и доделывать, потому как в нем не были учтены все детали проекта.
2) даже если большой проект разбивается на малые, то это ничего не дает. у малых проектов тоже есть риски в пределах 20%, сложите их - получите 80% и выше.
3) сейчас в работе проект с ~50 wireframes, 70 страницами ТЗ, пачкой use cases, html-прототипом проекта. это - большой проект (хотя бывают и больше). и весь этот объем документации при непосредственной разработке приходится менять и доделывать, потому как в нем не были учтены все детали проекта.
Точная оценка стоит очень дорого, и цена запросто может достичь 30% стоимости проекта. Заказчик либо понимает это и соглашается работать по примерной оценке, со всеми вытекающими последствиями, либо заказчик не понимает этого и все равно приходится работать по примерной оценке, тоже со всеми вытекающими последствиями.
Составление правильного контракта чем то мне напоминает получение точной оценки :)
Сколько видел контрактов, как правило там написан почти полный бред, и работа в конечном итоге все равно строится на доверии.
Составление правильного контракта чем то мне напоминает получение точной оценки :)
Сколько видел контрактов, как правило там написан почти полный бред, и работа в конечном итоге все равно строится на доверии.
С первым абзацем Вашего поста согласен на 100%.:) Точно оценить невозможно. И с оплатой по часам мало теперь кто соглашается работать. И я понимаю таких Заказчиков. Но как тогда оценить? Как тут ниже правильно отмечалось: либо выиграл ты, либо Заказчик. Но хочется сделать проект к обоюдному удовольствию сторон. Неужели невозможно? :)
А я такие контракты периодически составляю. :( Причем доверие хорошо только пока нет претензий, а как только они появляются все это доверие выходит страшным боком.
А я такие контракты периодически составляю. :( Причем доверие хорошо только пока нет претензий, а как только они появляются все это доверие выходит страшным боком.
по хорошему, все договора надо писать с почасовой оплатой, но только после того, как Вы изучили требования клиента и предоставили ему свои оценки в виде графика относительная вероятность поставки / время.
но в жизни все по другому, выставлять обычно нужно конечные счета, поэтому я пользуюсь оценкой основываясь на нескольких параметрах:
- доверие к заказчику
- опыт реализации подобных проектов
- суммарные риски проекта или величина временного диапазона от и до, в котором вероятность сдачи составит 100% (по сути расширение предыдущего пункта). такие рамки могут быть от 5 месяца до года, допустим, с пиком вероятностью поставки в 75%, который приходится примерно на 7 месяц разработки.
но в жизни все по другому, выставлять обычно нужно конечные счета, поэтому я пользуюсь оценкой основываясь на нескольких параметрах:
- доверие к заказчику
- опыт реализации подобных проектов
- суммарные риски проекта или величина временного диапазона от и до, в котором вероятность сдачи составит 100% (по сути расширение предыдущего пункта). такие рамки могут быть от 5 месяца до года, допустим, с пиком вероятностью поставки в 75%, который приходится примерно на 7 месяц разработки.
Мы говорим про классическую итеративную разработку или ее agile вариант? В первом случае окончательное решение всегда известно. Стоимость соответственно тоже можно определить (см. напр. RUP), в случае agile работать на fixed price в моем понимании просто невозможно.
Когда много представителей заказчика, задача тоже решаемая. Только нужно правильно организовывать общение с первым и заранее оговорить с ним даты и время нескольких презентаций проекта, в которых будут принимать участие все заинтересованные лица. Если в ходе презентации у этих представителей заказчика и возникают разные точки зрения, - это уже не проблема разработчика, а проблема заказчика и его команды. В этом случае разработчик вежливо уточняет, в какой день и во сколько можно получить согласованное представление о той части проекта, которая вызвала споры.
А вот это согласованное видео надо получать лично из рук первого лица и уточнять с ним все важные нюансы.
Презентации имеют и еще один плюс – они задают промежуточные «точки» проекта. И все участники презентации волей-неволей вникают в тонкости и нюансы разработки.
Таким образом, проводя презентации и правильно управляя общением представителей заказчика между собой можно выполнить задание в срок и вполне качественно.
А вот это согласованное видео надо получать лично из рук первого лица и уточнять с ним все важные нюансы.
Презентации имеют и еще один плюс – они задают промежуточные «точки» проекта. И все участники презентации волей-неволей вникают в тонкости и нюансы разработки.
Таким образом, проводя презентации и правильно управляя общением представителей заказчика между собой можно выполнить задание в срок и вполне качественно.
Всё прямо как из моей жизни с заказчиками. Иногда очень помогает сказать заказчику, что то, насколько разработчики поймут задачу, настолько хорошо будет реализовано задание, и то что всякие заплатки и патчи могут повлечь за собой появление дополнительных ошибок. Кстати статья хорошая.
А мы стараемся в разговоре с Заказчиком сразу расставить все точки над "ё".
1. Показать примеры готовых работ. Сделать упор на общий стиль и концепцию - нравится - продолжаем работать - нет - значит надо искать других Исполнителей. Иначе себе дороже работать.
2. Составление плана работ и среднего по объёму ТЗ. Все равно на 100% редко получается все реализовавать. Мы просто закладываем в смету дополнительные 20% работы.
3. Очень важно определить роли. Заказчик отвечает на вопрос "Что?" - дает исходное задание, в чём идея, задача, что нравится и т.д. Исполнитель отвечает на вопрос "Как?". И это очень важно сразу определить. Потому как если Заказчик начинает говорить, как надо делать дизайн - он занимается не своей работой - его работа - уменьшать риски компании и повышать прибыльность. Если есть несогласие - см. пункт №1.
4. Поэтапность работ. Показали макеты. Приняли? Получили подтверждение по e-mail-у? Значит Заказчик принял на себя обязательства по данному вопросу. Если потом возникают проблемы - отправляем к письму за нужную дату - "Сами утверждали?" - отвечайте. Или Заказчик (его представитель) некомпитентен.
5. На все вопросы "Ну, это ведь несложно сделать" - отвечаем, что и в работе президента банка тоже ничего сложного, однако, он получает свою зарплату. Если вы сами /переверстаете макет /настроите UNIX сервер /допишите программный модуль/ - мы будем на против. Но наша работа сверх ТЗ стоит Х рублей в час.
И если спокойно проговорить с Заказчиком основные моменты - можно выяснить - найдется у вас общий язык, или нет. Просто спокойно по-человечески поговорить. Обычно, люди (если к ним нормально относиться) довольно вменяемы.
З.Ы. Стоит брать 30% невозвращаемой предоплаты - так мне один Заказчик говорил - за что ему и благодарен. Спасибо, что дочитали :)
1. Показать примеры готовых работ. Сделать упор на общий стиль и концепцию - нравится - продолжаем работать - нет - значит надо искать других Исполнителей. Иначе себе дороже работать.
2. Составление плана работ и среднего по объёму ТЗ. Все равно на 100% редко получается все реализовавать. Мы просто закладываем в смету дополнительные 20% работы.
3. Очень важно определить роли. Заказчик отвечает на вопрос "Что?" - дает исходное задание, в чём идея, задача, что нравится и т.д. Исполнитель отвечает на вопрос "Как?". И это очень важно сразу определить. Потому как если Заказчик начинает говорить, как надо делать дизайн - он занимается не своей работой - его работа - уменьшать риски компании и повышать прибыльность. Если есть несогласие - см. пункт №1.
4. Поэтапность работ. Показали макеты. Приняли? Получили подтверждение по e-mail-у? Значит Заказчик принял на себя обязательства по данному вопросу. Если потом возникают проблемы - отправляем к письму за нужную дату - "Сами утверждали?" - отвечайте. Или Заказчик (его представитель) некомпитентен.
5. На все вопросы "Ну, это ведь несложно сделать" - отвечаем, что и в работе президента банка тоже ничего сложного, однако, он получает свою зарплату. Если вы сами /переверстаете макет /настроите UNIX сервер /допишите программный модуль/ - мы будем на против. Но наша работа сверх ТЗ стоит Х рублей в час.
И если спокойно проговорить с Заказчиком основные моменты - можно выяснить - найдется у вас общий язык, или нет. Просто спокойно по-человечески поговорить. Обычно, люди (если к ним нормально относиться) довольно вменяемы.
З.Ы. Стоит брать 30% невозвращаемой предоплаты - так мне один Заказчик говорил - за что ему и благодарен. Спасибо, что дочитали :)
В четвёртом пункте фигня какая-то. Лицом надо быть к Заказчику, лицом. Тогда он и денег охотнее будет приносить. Показали макеты? Показали. Заказчик не уверен в том, что макеты идеальны на 100%? Ну так и мы не уверены. Это ж макеты. Изменятся требования - переделаем и макеты. Не надо этого бояться :-) Заказчик хочет изменений - Заказчик платит.
Если Заказчик к вам лицом стоит - то да. А если, извините, жопой - то в зависимости от ситуации приходится эту жопу лизать, или наоборот, с это уязвленное место ...ть.
Макет - это не набросок. Когда на стадии принятия сайта вас просят тучу всего поменять, бесплатно, и еще вчера - это ненормально.
Макет - это не набросок. Когда на стадии принятия сайта вас просят тучу всего поменять, бесплатно, и еще вчера - это ненормально.
Я б в Ваш список добавил постановку целей текущего сайта. Сразу после демонстрации портфолио. Пусть заказчик определит устраивает ли его Ваш проф. уровень, Ваши идеи, если добавить к портфолио сопроводительное письмо которое описывает почему именно такая идея, именно такие технологии и т.д. После этого заказчик должен быть уверен в Вас как в человеке(компании), который(которая) сможет конвертировать его задачи в осязаемый результат.
После этого необходимо выяснить зачем нужен сайт, его приоритетные задачи, специфику его целевой аудитории. Дайте заказчику возможность почувствовать себе экспертом, но следите чтобы это экспертное мнение на распространялось дальше.
Зафиксировав разработайте ему предложение по реализации, основные аспекты, наброски идей. И снова подготовьте аргументы почему именно такая визуализация, почему именно такие решения.
Возможно скажу банальность но аргумент - "желтые буквы на синем фоне - это пошло" уступает по силе аргументу - "использование контрастов вызывает острую неприязнь у 35% Вашей потенциальной целевой аудитории"
После этого необходимо выяснить зачем нужен сайт, его приоритетные задачи, специфику его целевой аудитории. Дайте заказчику возможность почувствовать себе экспертом, но следите чтобы это экспертное мнение на распространялось дальше.
Зафиксировав разработайте ему предложение по реализации, основные аспекты, наброски идей. И снова подготовьте аргументы почему именно такая визуализация, почему именно такие решения.
Возможно скажу банальность но аргумент - "желтые буквы на синем фоне - это пошло" уступает по силе аргументу - "использование контрастов вызывает острую неприязнь у 35% Вашей потенциальной целевой аудитории"
На стадии принятия сайта? Бесплатно? Вчера? Ничего не понял.
Где итерации, бэклог, релизы?
Где итерации, бэклог, релизы?
1. Мне кажется, данная проблема лежит несколько глубже. Надо понять, по какой причине заказчик игнорирует предварительные материалы.. например, ему наплевать на проект, и для него он - отмазка, обязаловка или еще что-то. В этом случае МАСТ свалить как можно раньше и бесконфликтнее - успеха в таких проектах не бывает. Может быть, ему страшно вникать, он боится погружаться в очередную область знаний, где он не вполне уверенно себя чувствует. В этом случае надо дать заказчику ответ на его страхи и показать, что это - несложно. Может быть, он не знает, что именно вы от него ожидаете, с какой стороны ему подойти к материалам. В таком случае нужно вместе с ним пройти пару "уроков" и показать образец ожидаемого фидбека. Может быть, заказчик считает, что раз он уже объяснил вам, чего он хочет, то вы телепатически должны сами все сделать "правильно". В любом случае, без фидбека вы просто ставите работу на паузу и миролюбиво ждете. Давить на заказчика - опасно и неправильно, он будет испытывать не только психологический дискомфорт, но и точно будет знать, от кого он исходит. И в итоге может дать вынужденный фидбек, и это будет для вас еще хуже - вроде и фидбек есть и заново не потребуешь, а вроде и понятно, что фидбек ведет в пропасть. В любом случае, без личной заинтересованности заказчика в обсуждении задачи и проекта - проект никак не может состояться успешно, потому что понятие успеха в данном случае детерминируется заказчиком, а наш заказчик не может дать ответ на простые вопросы.
2. "Нет времени писать ТЗ" и "ТЗ должно быть всеобъемным и максимально точным" - на этих, казалось бы, диаметрально противоположных позициях могут стоять только дети, совсем недавно начавшие фрилансерскую карьеру или софтверный бизнес. Тут нечего говорить - работа и все соглашения должны быть продокументированы, просто не надо писать фолианты скучных тупых ТЗ, которые дружно все игнорируют. Надо понять не только суть, но и дух agile методологий - и вот тогда это работает. Еще неплохо бы несколько раз наступить на болезненные грабли, связанные с работой "на честном слове" - ну, а как иначе закреплять знания?:)
3. Работа сверх ТЗ должна оплачиваться. Это должно пониматься как нечто настолько само собой разумеещееся, что ни одной из сторон не придет в голову это обсуждать. Подчеркиваю - ни одной. Повторяю - обсуждать. По аналогии с рестораном - вы, конечно, можете поставить на стол бесплатные закуски, но это потому что вы угощаете, а не потому "тут так принято". И в ресторане вы ниче не обсуждаете, вы пришли, покушали, заплатили. Вы отработали столько-то часов - выставили счет - счет оплатили. Многие думают, что это возможно только с идеальным заказчиком в вакууме, но это не так. Это зависит только от того, как вы себя спозицинируете в отношениях и на какой уровень вы претендуете. (Естественно, это при условии вашего профессионального подхода. Контора, делающая сайты-за-$200, заслуживает к себе соответствующего отношения)
4. Заказчика обязательно надо держать в курсе методологии. В частности, МАСТ предупредить его о том, что никогда не бывает так, чтобы писалось ТЗ, создавался продукт и продукт сразу удовлетворял пожелания заказчика. Он должен понимать, что доводка будет обязательно, причем может по бюджету спокойно выйти даже на 100% сверх и эти затраты НЕ прогнозируются. Если заказчик с этим не согласен - вы НЕ РАБОТАЕТЕ, потому что иначе вы поставите шах и мат не только себе но и проекту. Ведь все равно недоведенный софт закзачик не примет (все проиграли), или доводку придется делать вам за свой счет (вы проиграли, заказчик выйграл).
5. Частая интеграция и показывание заказчику софта по мере готовности - палка о двух концах. С одной стороны, очень полезно, чтобы он шарил с вами ответственность за результат. С другой стороны, см.п.1. - фидбек может быть нерелевантен. С третей стороны, дураку полработы не показывают, а заказчик в области софта всегда дурак, потому что у него другая сфера компетенции.
2. "Нет времени писать ТЗ" и "ТЗ должно быть всеобъемным и максимально точным" - на этих, казалось бы, диаметрально противоположных позициях могут стоять только дети, совсем недавно начавшие фрилансерскую карьеру или софтверный бизнес. Тут нечего говорить - работа и все соглашения должны быть продокументированы, просто не надо писать фолианты скучных тупых ТЗ, которые дружно все игнорируют. Надо понять не только суть, но и дух agile методологий - и вот тогда это работает. Еще неплохо бы несколько раз наступить на болезненные грабли, связанные с работой "на честном слове" - ну, а как иначе закреплять знания?:)
3. Работа сверх ТЗ должна оплачиваться. Это должно пониматься как нечто настолько само собой разумеещееся, что ни одной из сторон не придет в голову это обсуждать. Подчеркиваю - ни одной. Повторяю - обсуждать. По аналогии с рестораном - вы, конечно, можете поставить на стол бесплатные закуски, но это потому что вы угощаете, а не потому "тут так принято". И в ресторане вы ниче не обсуждаете, вы пришли, покушали, заплатили. Вы отработали столько-то часов - выставили счет - счет оплатили. Многие думают, что это возможно только с идеальным заказчиком в вакууме, но это не так. Это зависит только от того, как вы себя спозицинируете в отношениях и на какой уровень вы претендуете. (Естественно, это при условии вашего профессионального подхода. Контора, делающая сайты-за-$200, заслуживает к себе соответствующего отношения)
4. Заказчика обязательно надо держать в курсе методологии. В частности, МАСТ предупредить его о том, что никогда не бывает так, чтобы писалось ТЗ, создавался продукт и продукт сразу удовлетворял пожелания заказчика. Он должен понимать, что доводка будет обязательно, причем может по бюджету спокойно выйти даже на 100% сверх и эти затраты НЕ прогнозируются. Если заказчик с этим не согласен - вы НЕ РАБОТАЕТЕ, потому что иначе вы поставите шах и мат не только себе но и проекту. Ведь все равно недоведенный софт закзачик не примет (все проиграли), или доводку придется делать вам за свой счет (вы проиграли, заказчик выйграл).
5. Частая интеграция и показывание заказчику софта по мере готовности - палка о двух концах. С одной стороны, очень полезно, чтобы он шарил с вами ответственность за результат. С другой стороны, см.п.1. - фидбек может быть нерелевантен. С третей стороны, дураку полработы не показывают, а заказчик в области софта всегда дурак, потому что у него другая сфера компетенции.
* Ранняя поставка билда
* Customer-on-site (хотя бы приближение к этому)
* Приоритет отношений между людьми и живой коммуникации над бумагами
решают проблему.
Вообще, если проект на более чем две недели и это не автоматизация четкого и неизменного бизнес-процесса, то попытки оценить сроки и трудозатраты ВСЕ и ЗАРАНЕЕ - это предрешенный провал. В таких случаях "буфер запаса" может доходить до сотен процентов (только на отладку - до 200% (с) Joel Spolsky)
* Customer-on-site (хотя бы приближение к этому)
* Приоритет отношений между людьми и живой коммуникации над бумагами
решают проблему.
Вообще, если проект на более чем две недели и это не автоматизация четкого и неизменного бизнес-процесса, то попытки оценить сроки и трудозатраты ВСЕ и ЗАРАНЕЕ - это предрешенный провал. В таких случаях "буфер запаса" может доходить до сотен процентов (только на отладку - до 200% (с) Joel Spolsky)
Насчет приоритета отношений: все это хорошо до тех пор пока не происходит ситуация описанная выше - смена людей в команде заказчика или поставщика решения (типично для проектов от полугода и более). Или же ситуация более типичная для отечественных заказчиков - уход в несознанку (Я такого не говорил, вы профессионалы не объяснили мне и т.п.) Если в такой ситуации документации ноль - работать становится очень некомфортно..
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление рисками, работа с заказчиком