Для фрилансеров и компаний, занимающихся разработкой программного обеспечения на заказ. Вас опять обломал заказчик? Потеряны деньги и время? Узнайте как прекратить череду обломов раз и навсегда

Нажмите Play, чтобы прослушать…

[Первая причина обломов]

Связанные записи

Share →

4 Responses to Опять обломал заказчик? Узнайте вторую причину, по которой это происходит и не допустите следующего облома

  1. Кстати из этого поста можно сделать интересный вывод. Разработчик, который постиг искусство обуздания сроков, да плюс к тому познал искусство поставить задачи и написать юзек-кейсы, должен этим размахивать, как офигенным конкурентным преимуществом. Ну и брать больше, естественно, хорошее не может быть дешево.

  2. admin:

    Да, именно так!

  3. Tango:

    1. «Видение» (ТЗ или даже минивариант ТЗ) — по сложности (и стоимости) может в несколько раз быть выше непосредственного написания программы.
    Поэтому разработчик ТЗ и программист — две разные профессии, требующие разных умений и совместить в одном в 90% случаев — нереально.
    2. Многие вещи вылазят в процессе — уточнения, доп пожелания, отмена предыдущих уточнений и пожеланий… Причем это присходит ВСЕГДА :).
    3. Есть типовые задачи и не типовые. Вторые — всегда слабопрогнозируемые по срокам (чем-то сродни научным исследованиям).
    4. Я когда сталкивался с этими проблемами пытался создавать такую систему отношений, при которой:
    а) Задача разбита на мелкие подзадачи по критерию «не жалко денег».
    б) Подзадачи должны при желании легко передаваться другим разработчикам (документированность и ясность кода).

    Касательно 4.а:
    Деньги выплачиваются по завершении каждой подзадачи.
    Соответственно — кидалово может произойти на сумму подзадачи, а поскольку подзадача обусловлена суммой «не жалко денег», то потери минимальны.

    Касательно 4.б:
    Можно организовать даже конкуренцию (явную или неявную) когда одна подзадача реализовывается разными разработчиками и менеджер выбирает лучший вариант (потеря денег опять же на уровне: «не жалко…»).
    Кроме того уход от главной ошибки — зависимости от разработчика, который получив заказ и аванс (или проделав часть работы) зачастую начинает диктовать условия и сроки, капризничать, считая, что слишком много потрачено и от него уже никуда не денутся — можно и расслабится. 🙂

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

  4. Что касается сроков на видение и ТЗ, то мы в своё время поступали так:
    1) Делали предварительную оценку с погрешностью 700%
    2) Заказчик оплачивал составление ТЗ и погрешность в оценке после этого составляла где-то 20-30%
    3) Делали итеративным методом, что позволяло нам вносить все правки заказчика и успевать в срок

Добавить комментарий