MyStory: Недостижимое отставание

The Ultimate inspiration is the Deadline

После отпуска нужно обязательно сразу же взяться за интересный кейс. Мозги отдохнули и теперь требуется разминка. Получил на емейл очень сложный кейс о работе команды разработки с крупным Заказчиком. Ситуация непростая, так что мнения читателей очень приветствуется:

 Две большие компании (заказчик и подрядчик), сотрудничающие по огромному ряду направлений (от железа до консалтинга).

Заказчик ключевой, поэтому крайне важен для подрядчика. Подрядчик реализует проект по разработке и внедрению очень сложного (логически) внутреннего ПО. Проект – fixed price, но (повторюсь) сложный, не типичный, длительный. В силу определенного ряда обстоятельств проект продан очень дешево (как для такой разработки).

 В процессе проекта у заказчика как обычно возникают доп. хотелки. Срок проекта один раз перенесен, бюджет немного расширен, и доп. хотелки добавлены в скоуп.

 Проект в срок не заканчивается, подрядчик получает штрафные санкции и срок проекта опять переносится.

 Когда подходит дата завершения проекта (уже с учетом всех переносов) разработка завершена, предварительное тестирование завершено, тестирование на стороне заказчика не завершено (т.к. система очень сложная и высоконагруженная, много интеграции и зависимости от других систем заказчика, заказчик довольно бюрократичен). Проект принимается заказчиком “авансом” на основании гарантийного письма подрядчика о том, что в течении еще двух недель подрядчик не снимает команду с проекта, и устраняет все найденные заказчиком дефекты.

 За две недели заказчик систему не протестировал, ссылаясь на то, что система сырая, постоянно возникают проблемы, не позволяющие систему тестировать. Тестирование не закончилось и в течении 2.5 месяцев – команда у подрядчика не расформирована (я писал выше, что заказчик очень важен для подрядчика), заказчик ссылается на гарантийное письмо с обязательством подрядчика устранить дефекты, найденные заказчиком (срок, указанный в этом письме, игнорируется). Работы подрядчика не оплачиваются, т.к. контракт на поддержку можно заключить только когда система будет запущена в эксплуатацию. Дата такого запуска постоянно переносится заказчиком (опять же по словам заказчика из-за того, что в системе еще находятся дефекты). Т.к. система долго не запускалась за это время бизнес поменялся, и уже возникли дополнительные задачи, без реализации которых систему запустить нельзя (а эти доп. фичи также нужно будет тестировать).

 Какие будут рекомендации? :)

 Интересны как рекомендации о том, что делать дальше, так и разбор основных ошибок, которые сделаны в ходе выполнения проекта. Вроде некоторые ошибки видны невооруженным глазом, но каждая из них имеет вескую причину. Что же делать?

Комментируйте и Пишите о своих кейсах! Наш опыт помогает другим. В этом можно убедиться, просмотрев уже разобранные кейсы на сайте anotherpm.com.

Sep 19th, 2011
  1. Sep 19th, 2011 at 21:32 | #1

    По-хорошему, любой бизнес ориентированный на одного заказчика – это риск стремящийся к 100%. Телесенс нам всем должен был стать примером, но вероятно не стал.
    Что нужно делать? Очевидно диверсифицировать источники дохода и отчетливо дать понять заказчику, что договор есть договор и его соблюдение обязательно для обоих сторон-участников. Эту мысль нужно как-то поселить в голове у заказчика, откуда она уже давно выветрилась – а ну-ка, 2,5 месяца получать результаты “тестирования” бесплатно!
    Вот этого НЕ НАДО БЫЛО делать ни в коему случае. 2 недели должны были закончится 2мя неделями. Надо учиться говорить “нет”. А это очень сильно помогает делать диверсификация источников дохода.
    Такая вот, загогулина :)

  2. Sep 19th, 2011 at 22:18 | #2

    Согласен с Антоном, всё так.
    Хотелось бы только отметить, что тут если уж прогнулся однажды, то прогнёшься и во второй, и в третий, и в десятый раз. Не стоило позволять и двух недель. Заказчику необходимо протестировать систему? ОК, пусть тестирует. Команду необходимо снимать с проекта (а что ей там делать?), оставив нескольких человек на саппорт. После тестирования – составить акт приёмки, в котором указать критические дефекты системы. После этого договориться о сроке их исправления, исправить, проверить что критические дефекты исправлены, а приемо-сдаточные тесты проходят. И если после этого у бизнеса появились новые потребности – подписать новый договор, с новыми сроками и оплатой. Иначе этот “иссушающий” бизнес не принесёт пользы ни заказчику, ни исполнителю.

  3. Damiano
    Sep 19th, 2011 at 22:48 | #3

    мнится мне, что рекомендации “в песок” пойдут. без нас с вами договорятся за откат или на работах железу/консалтингу/… будет сделан напиллинг.
    как управлять рисками масштаба предприятия – это конечно хороший вопрос. аудитория вот только может быть не та :)
    кейс здорово вырван из контекста и полная фактология может быть чуть более чем недоступна. так что любые рекомендации будут измышлениями “на тему”.
    имхо.

    • covrom
      Sep 20th, 2011 at 06:04 | #4

      Судя по кейсу, для РП это все неизвестный ему политический контекст. Его косяк, что он ничего не знает. Но с другой стороны, ему нужно сделать все что от него зависит. Распил делают другие люди, и если РП ничего не будет делать, то его либо в расход пустят (работу искать с негативной репутацией заваленного проекта), либо он по-максимуму продемонстрирует, что хоть чем-то да управляет и сделал все что мог.

    • Sep 20th, 2011 at 21:35 | #5

      аудитория точно не та, Дим. во всяком для обсуждения распилов и откатов. волшебный мир внутреннего рынка постсовка – это абсолютная Terra Incognita и я приложу максимум усилий, чтобы так и оставалось для меня как можно дольше. я эту мерзость руками трогал только один раз – у меня на всю жизнь рвотный рефлекс остался.

  4. Sep 20th, 2011 at 00:04 | #6

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

    Главная проблема немного другая – заказчик недоплатил около 10% контракта, по исправно платит за новые фичи. Но дело в том, что под “фичи” попадает маловато программерского времени. Поэтому проект выходит почти в 0 (небольшой убыток)

    Я собираюсь решать зафиксировав scope, сфокусировавшись на фиксе багов и сдав проект в текущем состоянии. Саппорт, естественно, останется, основной проект с клиентом сворачивается.

    В кейсе это сделать нереально, надо садиться и договариваться. Подрядчик нужен клиенту так же как и наоборот, на этом и надо акцентировать внимание и свести проект к нормальной прибыльности для компании, может сделав небольшую скидку – 10-15% или около того. Косяки со стороны команды 100% есть и немало. Иначе проект так не сдается, только в случае неадекватного клиента. А исходя из того что клиент большокй и постоянные, считаю что он адекватный

    • covrom
      Sep 20th, 2011 at 06:01 | #7

      Я собираюсь решать зафиксировав scope, сфокусировавшись на фиксе багов и сдав проект в текущем состоянии. Саппорт, естественно, останется, основной проект с клиентом сворачивается.

      Не сработает. Вы этим говорите заказчику, что хрен ему а не не нужная ему система. Система работать не будет, все будут недовольны, новых подрядов не дадут, со временем и саппорт у вас тоже отберут.

      • Sep 20th, 2011 at 11:18 | #8

        Скажем так. Клиент УЖЕ ПОЛЬЗУЕТСЯ системой 4 месяца и в течение этого времени на базовый функционал навернули около 25% нового, параллельно фиксив баги. В базовом функционале багов теберь нет (почти), только в дополнительном.
        Ну а прощаться с этим клиентом я и сам бы рад, но он этого делать не будет, потому что саппорт от другой компании он не потянет по деньгам.

  5. covrom
    Sep 20th, 2011 at 05:56 | #9

    Классика ИТ-проектов в России. Основная ошибка – нет никакого управления интересами и требованиями сторон, т.е. нет убедительного РП. Вторая ошибка – нет никакой работы с проектной командой, во всем обвиняется заказчик, хотя очевидно что проблема в исполнителях.

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

    Вывод №2 – срочное авторитарное управление командой проекта (и людьми исполнителя, и людьми заказчика). Все сопли про человеколюбие и специфику ИТ – выкинуть в мусорное ведро, это уже не сработало. Ленивых – выгнать, работящих – поощрять. Для этого РП должен сам быть сильным ИТ-специалистом (как минимум не ламером), чтобы его авторитаризм был принят исполнителями. Выделить на это финансирование внутри подрядчика (спонсирование должно теперь добавиться и от собственника бизнеса подрядчика). Снизить норму рентабельности проекта.

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

    • Sep 20th, 2011 at 21:51 | #10

      Тут вот какая есть “закавыка” в предложенном варианте.

      Во-первых, раз проект идет долго, то “антикризисный мененджер” будет въезжать как минимум полгода в скоуп, договоренности, контракты, обещания и т.д.
      Во-вторых, авторитарность – это хорошо. Всегда хорошо, когда у менеджера есть авторитет. Но айтишники (особенно толковые), они же не глупые ребята, их “галстуками” не возьмешь. Авторитеты бывают нескольких типов (экспертные, лидерские и силы). Экспертом явно не станешь быстро, лидер – возможно (но опять же не быстро), а силу применять при текущем рынке дефицита кадров можно недолго. Просто люди уйдут и все. А чего стоит замена ведущего спеца в таком долгоиграющем проекте, я думаю, что вы понимаете.

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

      • Sep 21st, 2011 at 05:58 | #11

        Политически сильные айтишники – это полный провал менеджмента. Если вы так сильно зависите от персонала в заваленном (уже заваленном) проекте – то первое от чего надо избавиться – это от этой зависимости. Люди все-равно уйдут, потому что никто не хочет иметь дело с неудачниками в неудачном проекте. Думать, что вы удерживаете компетенции в заваленном проекте при помощи удержания тех же людей – ошибка. Эти люди уже не справились и не справятся и дальше. Так что риск есть, но он может быть как отрицательным, так и положительным.

  6. covrom
    Sep 20th, 2011 at 06:10 | #12

    И еще важное упоминание в кейсе – “за это время бизнес заказчика поменялся”. А чем думал РП когда план проекта делал? Он это изменение не учел? Плыл по единственному базовому водопаду? Надо было учесть, делать итерации, а не пытаться доделать неработоспособную систему со срывом сроков.

  7. Aleks
    Sep 20th, 2011 at 08:00 | #13

    Еще предложение провести такие мероприятия:
    1) с Заказчиком определить ответственного за прием проекта от Заказчика. Или несколько ответственных по подразделениям;
    2) со стороны Подрядчика предоставить Заказчику своего сотрудника на полные рабочие дни, который сможет протестировать ПО на территории Заказчика и в тесном сотрудничестве с ответственными от Заказчика;
    3) определить сроки по каждому разделу ПО (разделы == подразделения Заказчика?);
    4) с ответственными определить актуальные разделы ПО и тестировать только их. Устаревшие разделы ПО (возможно они понадобятся в будущем Заказчика. Тогда можно будет их восстановить, протестировать, актуализировать) убрать в архив;
    5) обговорить с Заказчиком возможность ввести процентовки (% выполненных от общего количества работ). Принятые и актированные разделы ПО оплачивать согласно процентовке.

  8. Smaylukk
    Sep 20th, 2011 at 08:02 | #14

    Побывав в такой же ситуации, хочу предложить и свои решения:
    - пересмотреть с руководством подрядчика “важность” заказчика. Если скажут, что важен – тогда не ныть и продолжать работать, потому как уже ничего изменить не сумеете, заказчик понял свою важность и здесь он будет диктовать условия, а не вы.
    - с решением “не очень важен” прийти к заказчику и начать пересмотр текущих условий проекта: перевести команду на “N у.е./мес”, оговорить точные сроки сдачи проект, постоянно уточнять информацию о тестировании проекта.

    P.S. Очень важным заказчик для подрядчика может быть только если подрядчик есть ИТ департаментом/отделом у заказчика, в противных случаях важность можно и нужно менять

    • Sep 20th, 2011 at 21:13 | #15

      - пересмотреть с руководством подрядчика “важность” заказчика. Если скажут, что важен – тогда не ныть и продолжать работать, потому как уже ничего изменить не сумеете, заказчик понял свою важность и здесь он будет диктовать условия, а не вы

      Абсолютно, целиком и полностью не согласен. Это рабская психология “не ныть и продолжать работу”. Забудьте про барина, забудьте про “клиент всегда прав” – специалист или команда специалистов найдет себе работу всегда. Тем более сейчас. Так что если руководство подрядчика не собирается вести себя адекватно – адиос мучачос, муча грациос. И пусть сами решают теперь уже исключительно свои проблемы со своим заказчиком.
      Под “повести себя адекватно” я имею в виду второй предложенный Вами вариант.

  9. Casper
    Sep 20th, 2011 at 09:47 | #16

    Я бы поступил следующим образом:
    1. Хоть уже и поздно, но все же отправить на территорию Заказчика сотрудника, разбирающегося в разработанном ПО и бизнеспроцессах Заказчика для участия тестировании разработанного ПО (как было указано ранее).
    2. Жестко разделить “хотелки” от реальных багов. Назначить приоритет каждого бага (в т.ч. и в зависимости от важности модуля, как отмечено “Aleks”) и заниматься исправлением только приоритетов High и Critical.
    3. Сократить число людей, участвующих в разработке путем переключение топовых специалистов и части специалистов среднего звена на разработку доходных проектов, тем самым понизив приоритет разработки для топовых специалистов до уровня поддержки разработчиков среднего и низшего звена.
    5. Понизить приоритет исправления багов для специалистов среднего звена до “средний”.

    На мой взгляд это позволит сократить расходы на проект (з/п топовых спецов гораздо выше и будет исчисляться им с других проектов; количество человек, необходимое на разработку выше, чем на поддержку, следовательно, освободившиеся ресурсы перекинуть на другой проект, вследствии чего получится экономия), снижение приоритета проекта позволит финансово “вытащить” команду за счет исполнения других проектов. Т.о. Заказчик не будет считать себя “кинутым” в то же время позволит одновременно решать команде другие задачи.

    • Sep 20th, 2011 at 11:36 | #17

      Casper :
      Я бы поступил следующим образом:
      1. Хоть уже и поздно, но все же отправить на территорию Заказчика сотрудника, разбирающегося в разработанном ПО и бизнеспроцессах Заказчика для участия тестировании разработанного ПО (как было указано ранее).

      Ага, командировка в США учитывая что проблема проекта именно в бюджете :)

      2. Жестко разделить “хотелки” от реальных багов. Назначить приоритет каждого бага (в т.ч. и в зависимости от важности модуля, как отмечено “Aleks”) и заниматься исправлением только приоритетов High и Critical.

      Как отметил covrom, номер не проходит, потому что заказчик не получает систему, которая ему реально нужна.

      3. Сократить число людей, участвующих в разработке путем переключение топовых специалистов и части специалистов среднего звена на разработку доходных проектов, тем самым понизив приоритет разработки для топовых специалистов до уровня поддержки разработчиков среднего и низшего звена.
      5. Понизить приоритет исправления багов для специалистов среднего звена до “средний”.

      И получить еще более низкоквалифицированную команду, которая будет делать еще менее качественный продукт?

      На мой взгляд это позволит сократить расходы на проект (з/п топовых спецов гораздо выше и будет исчисляться им с других проектов; количество человек, необходимое на разработку выше, чем на поддержку, следовательно, освободившиеся ресурсы перекинуть на другой проект, вследствии чего получится экономия), снижение приоритета проекта позволит финансово “вытащить” команду за счет исполнения других проектов. Т.о. Заказчик не будет считать себя “кинутым” в то же время позволит одновременно решать команде другие задачи.

      не думаю, что так получится. Квалификация команды упадет, новые требования не будут обрабатываться. Думаю будет еще большая ж…а

  10. SergeyMarkov
    Sep 20th, 2011 at 10:13 | #18

    Кейс интерестный, мне напомнило сразу 3 проекта с практики.
    Я увидел следующее, которое вызывает интерес :
    - Поставка продукта происходила в 1 этап? Все сразу взяли и отдали. В сложной системе это очень опасно. Понять/протестировать/разобраться/решить то или не то в течении 2 недель будет крайне важно. В таких системах (работал на 3 таких проектах – в одном проблем не было :) ) важен фидбек от пользователей именно, их может быть много и вытянуть инфу с них не так просто, на пару недель обычно не успеть. Нужно чаще демонстрировать сделанную работу и заставлять “тыкать” продукт и давать фидбек.
    - Беда с критериями приемки. В сложных системах, а тем более фиксед-прайс это смерть. Если нет – цепляться можно ко всему что не так смотрится.
    - Что касается того, что за 2 недели не успели протестить, мотивирую кучей недостатков. В практике было именно вот так, 100%. Я добился удаленной приемки. Так сказать, не то что мы вам не верим, верим конечно!, но просто хотим увидеть чтобы быстрей отреагировать и пофиксить, Вам же лучше сделать! Недоработок стало гораздо, раз эдак в 5 меньше, как только мы стали наблюдать все.

    - По новым фичам. Я бы попробовал лезть не в фиксед прайс, а в что-то погибче (T&M, разные вариации FP). Если заказчик уперт и хочет фиксед прайс – не подписывайте большие куски – подписывайте на месяц (и каждый месяц заново подписывайте). Так будет проще сдавать продукт. Чаще фидбек, чаще общение. На полугоднем интервале намного легче “слажать” и бизнес больше поменяется. Т.е. вам намного сложней. Как вариант я бы попробовал вот так. Ну или Agile. По моим похожим проектам – это очень даже хорошее решение было (к сожалению опробовал только на 1 проекте).

    + Соглашусь с мнением ребят выше. Раз уж он вам машет бумажками перед лицом, помашите и вы. Связь двухстороняя быть должна. Если клиент вас совсем не хочет понять, услышать и паразитирует на вас…. нужен ли он Вам ? (читать самый крайний вариант :) )

  11. Sep 20th, 2011 at 11:25 | #19

    covrom :
    Классика ИТ-проектов в России. Основная ошибка – нет никакого управления интересами и требованиями сторон, т.е. нет убедительного РП. Вторая ошибка – нет никакой работы с проектной командой, во всем обвиняется заказчик, хотя очевидно что проблема в исполнителях.

    В моем случае был жесткий underestimate, а за проект взялись потому что других не было. Думаю здесь схожая ситуация. Говорить о том, что требования не анализировались или что для клиента не старались а делали … неверно. Просто определить требования, даже при условии что ему помогают – делают прототипы интерфейсов, показывают готовые части и т.п. достаточно сложно. Он хотел построить систему, аналогов которой нет, но охватить все аспекты своего бизнеса в деталях он не мог.

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

    Вывод №2 – срочное авторитарное управление командой проекта (и людьми исполнителя, и людьми заказчика). Все сопли про человеколюбие и специфику ИТ – выкинуть в мусорное ведро, это уже не сработало. Ленивых – выгнать, работящих – поощрять. Для этого РП должен сам быть сильным ИТ-специалистом (как минимум не ламером), чтобы его авторитаризм был принят исполнителями. Выделить на это финансирование внутри подрядчика (спонсирование должно теперь добавиться и от собственника бизнеса подрядчика). Снизить норму рентабельности проекта.

    У меня такой проблемы нет, хотя и хожу в джинсе :) Проблема решалась примерно вашими способами. Но дело в том, что добившись стабильности в базовом функционале (на который был заключет контракт fixed price), мы получили ситуацию что “все работает, но многого не хватает”. Понять это я сам не мог, потому что клиент не хотел прорабатывать все скрины до конца – “и так понятно”. А когда доделали, оказалось что нифига непонятно. Проблему решил бы полный прототип, но это увеличивало бюджет раза в полтора, что было неприемлимо для клиента.

  12. Sep 20th, 2011 at 11:27 | #20

    В защиту подрядчика – бывает что клиент тупо не хочет попробовать поюзать полуготовый продукт (результат 3-4 итераций), говорит что хочет сразу в боевых условиях и все вместе. А пока доделано все вместе, то и бизнес клиента немного меняется.

    • Sep 20th, 2011 at 11:37 | #21

      Поюзать сам не хочет, а на демо уверенно кивает – да, это оно, да все верно. На уточняющие вопросы не всегда может найти ответы, откладывает на потом. Это все выливается потом в такие кейсы.

  13. Sep 20th, 2011 at 11:38 | #22

    SergeyMarkov :
    - Что касается того, что за 2 недели не успели протестить, мотивирую кучей недостатков. В практике было именно вот так, 100%. Я добился удаленной приемки. Так сказать, не то что мы вам не верим, верим конечно!, но просто хотим увидеть чтобы быстрей отреагировать и пофиксить, Вам же лучше сделать! Недоработок стало гораздо, раз эдак в 5 меньше, как только мы стали наблюдать все.

    Не понял, что именно вы сделали?

  14. Sergey.M
    Sep 20th, 2011 at 12:56 | #23

    Не понял, что именно вы сделали?

    Я договорился о приемке с нами вместе. Т.е. чтобы мы видели процесс тестирования/приемки с их стороны (расшарить десктоп, кого-то к ним отправить – тут не суть как реализовать). Можно сказать что есть куча недостатков, если не понимать что и как юзается. Когда их специалист пытался показать “вот те недостатки”, то оказалось, что это совсем не недостатки. А они просто сами не в курсе как быть должно и делали совсем не то что нужно. Компания большая, бюрократия у них развита, соответственно могли принимать по разным версиям заявленных документов, на неверной настройке etc… Когда вы все наблюдаете, вы сразу их поправляете. Мне это очень помогло.
    В моем кейсе, что я от этого выиграл, когда наблюдал приемку:
    - Они сверяли совсем не с той докой, с которой нужно было
    - Выполняли люди, которые вообще не в курсе системы были (было очень много “глупых” вопросов). В стиле “Эй Женя! Тебе делать все равно нечего, сядь приемку сделай. Смотри только хорошо, ато потом лозиной тебя если че…” А Женя системы ни разу в глаза не видел, вот и понаписывал хз чего, и зафейлил, ибо лозины боится. Ну а видя 50 фейлов, естессна в них наврят кто будет разбираться и выяснять что-то.. Сразу и сказали вам что “не годится”
    - Неправильное оборудование было уставлено (и конфигурации)
    - Неверные настройки при инстале (мануалку проигнорили, поставили абы как и побыстрей)
    - У меня система была очень большая. Допустим пусть будет 10 частей. С каждой частью работает определенная группа людей. Т.е. 100 человек работает с фичей А, 100 с фичей Б, 100 с фичей В… Приемку делал чувак только с одной группы. В этом была трабла, так как он не понимал бизнесс целей других фич системы. Про интеграцию даже говорить боюсь :)

  15. Sergey.M
    Sep 20th, 2011 at 13:20 | #24

    Konstantin :
    Поюзать сам не хочет, а на демо уверенно кивает – да, это оно, да все верно. На уточняющие вопросы не всегда может найти ответы, откладывает на потом. Это все выливается потом в такие кейсы.

    1. Попробуйте документировать в жесткой форме после каждого “кивания”. Пишите после демо что-то в стиле “Окей. Тогда фичу А и Б больше не меняем. Остается вот такой и все. Согласны ?”
    2. Нужно кого-то засылать к клиенту, на месяц, два… В живую пинать намного проще. Если не может клиент общаться, нет времени, ищите других контакт-персонов, кто сможет адекватно отвечать на вопросы.
    3. Попробуйте показать графиками, обрисуйте процесс и покажите, как сложно все менять, когда уже написано все. (Лучше это показывать не удаленно, а в живом общении).

    + пара вопросов:
    1. У вас клиент не из СНГ случайно ( у меня такие были, с ними сложно)?
    2. Он в технической части имеет скилы?
    3. На его стороне есть еще люди, которые принимают решения, или он один Big Boss и все ?

    • Sep 20th, 2011 at 21:17 | #25

      Таки очень похоже на организацию, пораженную метастазами совка. Но далеко не факт, западные коллеги иногда даже поразить воображение умеют, не то что просто удивить :)

  16. Mariya
    Sep 20th, 2011 at 13:51 | #26

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

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

  17. Mikhail
    Sep 20th, 2011 at 16:53 | #27

    У меня предложение немного другое: закройте глаза, забудьте о своих проблемах и представьте себя на месте заказчика. Подумайте над его проблемами.

    - Почему он тестирует не вовремя? Ему не хватает времени? Может быть, он просто боится, что, подписав сдачу, вас потеряет? А может, действительно, мешают ошибки, не дающие протестировать нормально?

    - Почему он не запускает проект? Он не уверен в его качестве? Есть какие-то другие, неизвестные вам политические мотивы? Он сам заинтересован в его пуске?

    Дальше я бы написал такое письмо:

    —–

    Уважаемый мистер Х.

    Как вы, вероятно заметили, у нас в проекте сложилась патовая ситуация: вы не можете протестировать проект и предоставить нам полный финальный список дефектов. Соответственно, мы не имеем возможности завершить его основную фазу и перейти к дополнительной функциональности.

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

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

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

    Именно поэтому мы предлагаем следующий план действий на ближайшие две недели:

    1. С текущего дня мы перестаём рассматривать любые изменения функциональности до тех пор, пока акт приёмки текущих работ не будет подписан.
    2. До вы предоставляете план приёмочного тестирования, чтобы мы могли убедиться, что все дефекты, мешающие приёмке устранены. Если по какой-то причине вы не можете составить такой план, мы можем предложить свой вариант к и согласовать его до
    3. Мы исправляем все дефекты, препятствующих приёмочному тестированию
    4. После предоставления вам исправленной версии, вы проводите приёмочное тестирование в течение трёх дней, после чего предоставляете нам отчёт и список найденных дефектов. Дефекты, найденные после предоставления данного списка будут являться предметом отдельного договора.
    5. В течение двух недель, мы исправляем данные дефекты и подписываем акт приёмки.
    6. После текущей приёмки мы начинаем следующую фазу разработки и реализации внесённых изменений.

    Пожалуйста, внесите в данный план исправления, которые считаете необходимыми.

    Я очень сожалею, что мне приходится писать заявления в такой ультимативной форме, но в данный момент это – единственный вариант, позволяющий нам выполнить данный проект без критических потерь для бизнеса, а вам – получить работающее ПО, затраты на которое и для нас и для вас достаточно внушительны.

    Надеюсь, что мы сможем придти к соглашению.
    С уважением,
    Мистер Y

    • Sep 20th, 2011 at 21:56 | #28

      Михаил,

      Очень толковое предложение. Правильная позиция о том, что мы ищем конструктивного решения проблем.
      Единственное, что смущает меня, так это немного ультимативная форма письма (хотя я лично писал бы именно так). Если представить, что Заказчик не очень счастлив (а это вероятно факт), то такое письмо может действовать на него как красная тряпка. Выражения “Что значит эти … не будут больше рассматривать любые изменения функциональности? Система не работает, а они диктуют нам что они будут делать!!!!!”.
      Боюсь это будет серьезный “Шкандаль!”

      Хотя с другой стороны тут без скандала и выяснения позиций будет тяжело “расшевелить” эту ситуацию.

  18. Oxana
    Sep 20th, 2011 at 17:05 | #29

    Прочитала кейс, который вы описали и хотела бы поделиться своими соображениями.

    В процессе чтения у меня сложилось мнение, возможно я ошибаюсь, но мне так показалось, что подрядчик слишком заинтересован в заказчике. Я бы даже сказала, через чур. Я понимаю, что это ключевой заказчик и от него многое зависит, но подрядчик от большого желания угодить в итоге стал выглядеть непрофессионально и, что называется, “потерял лицо”. Объясню, что я имею в виду.

    В кейсе неоднократно подчеркивается, что проект большой, сложный, длительный, а также неординарный, со сложной логикой. Если это так, то ошибкой было соглашаться на fixed price. Fixed price вообще сейчас большая редкость. И это больше для проектов простых и небольших по времени, ресурсам и скоупу. А тут такие “навороты” и вдруг fixed price. Даже если подобрана команда супер-профессионалов, очень трудно заэстимировать все риски, все имплементации, интеграции, тестирование и прочее на таком большом проекте, нереально предусмотреть все и сразу на длительный период времени вперед. Обязательно что-то пойдет не так, как планировали, заказчик придумает делать новую мега-важную фичу, изменится состав команды, может произойти все, что угодно. И как результат, приложение не будет готово в срок. А это на fixed-price проектах автоматически означает штрафные санкции. А по итогам это неудовлетворенный заказчик, команда подрядчика на нервах, и приложение не такого качества, как хотелось бы.

    Идем дальше. Заказчик тестирует систему на протяжении 2,5 месяцев и присылает репорты о все новых и новых багах. Вопрос к команде тестирования: в самом начале проекта был ли написан тест план, в котором четко прописаны acceptance criteria приложения? У меня складывается ощущение, что нет. Либо этих критериев не придерживается ни подрядчик, ни заказчик. Если критерии не разработаны, самое время это сделать. Это позволит определить финальную точку, которой должны достигнуть. И это должно быть что-то более реальное, чем “светлое будущее”. Если критерии были разработаны и одобрены заказчиком и уже достигнуты при сдаче приложения, тогда подрядчику стоит вежливо, но твердо дать понять заказчику, что свои обязательства они выполнили, и перестать тратить время на багфиксинг.

    В конце кейса упоминается, что у заказчика возникли дополнительные фичи, без которых невозможно запустить проект. Если я правильно понимаю, заказчик снова хочет сыграть на чувстве вины подрядчика и стрясти с него новые фичи за бесплатно. Это хороший момент, когда можно убедить заказчика перейти на time-material. У заказчика есть заинтересованность в том, чтобы продолжать работу. Даже если ему будет не очень выгоден переход, он может пойти на уступки, чтобы получить доработку и стать, наконец, счастливым. Подрядчику же это будет выгодно тем, что его команда перестанет работать в убыток, и раз заказчик такой плодовитый на идеи, – это значит долгосрочное сотрудничество. О чем еще можно мечтать?

    А в общем, могу сказать, что подрядчику нужно расти. Много и быстро учится и расти над собой. Потому что все то “безобразие”, которое описано в кейсе, получилось из-за того, что подрядчику не хватает смелости, разговорчивости и опыта. Надо садиться за книги по менеджменту и психологии, надо ходить на курсы, надо учиться убеждать людей в том, что считаешь правильным и полезным. И не скупиться на опытных сотрудников: в случае, когда вам не хватает опыта и зашли в тупик, они могут подсказать интересное решение.

    • Sep 20th, 2011 at 20:07 | #30

      Оксана, сложно с вами согласиться.
      Все что вы пишите – правильно, но не всегда и не везде.
      Fixed Price далеко не редкость, особенно при работе с госзаказчиками и крупными госкорпорациями.
      Судя по комментариям – речь идет не о таком заказчике (упоминалась америка), и мы не знаем почему пошли на фиксед прайс, но реальность именно такова.
      Один из немногих вариантов, который тут может подойти – это описанный выше Михаилом. Но он возможен только если руководство подрядчика готово потерять этого клиента ведь такой исход вполне возможен.
      Если же не готовы потерять – то выхода практически нет. Можно попробовать практически все предложенные методы, но ни один из них может не сработать.
      PS. Исхожу из своего опыта работы с крупным госом тоже на сложном и длительном проекте и с очень похожей ситуации (сначала даже подумала что речь именно про нее).

  19. Sep 20th, 2011 at 18:58 | #31

    Внесу и я свои 5-ть копеек.

    Не буду повторять, то что уже так или иначе порекомендовали, но остановлюсь на том, что на мой взгляд должен быть стремится сделать ПМ, чтобы не “потерять лицо” внутри компании.

    В определенный момент, когда стала понятна ситуация, а понятна она стала с самого начала (фикс + сложная логика + возможно НИОКР), надо было выводить этот проект внутри компании как “репутационный” и, соответственно, на внутреннюю модель “время+материалы”.

    Таким образом ПМ сразу давал понять боссам, что он все понимает и в детские игры со сроками и виной играть не будет по крайней мере внутри своей песочницы.

    Собственно и выходить из этой ситуации (если нельзя просто послать нах) рекомендую начать с этого шага.

  20. Sep 20th, 2011 at 21:29 | #32

    Вторая ошибка – нет никакой работы с проектной командой, во всем обвиняется заказчик, хотя очевидно что проблема в исполнителях.

    Я бы сказал, совсем не очевидно. Вы не поверите, но очень часто, примерно в 40-50% случаев проблема именно в заказчике.

    Для этого надо обладать весом и авторитетом, ходить в костюме и галстуке с дорогим портфелем, а не в джинсе.

    Классический для России стереотип: обладать авторитетом == ходить в дорогом костюме, ездить на большом и непременно ЧЕРНОМ джипаре…. Малиновый пиджак и золотую цепь уже не можно носить?
    А если совсем серьезно – еще не родился директор, который заставит меня носить костюм, галстук и прочую ерунду. Мои знания и моя полезность никак не коррелирует с моей манерой одеваться. Человек, который не способен этого понять, по определению не может стать моим руководителем.

    Вывод №2 – срочное авторитарное управление командой проекта (и людьми исполнителя, и людьми заказчика).

    С этого момента мифический РП с растопыренными пальцами в дорогом костюме садиться за компьютер и решает задачу самостоятельно. Предварительно он был послан по известному адресу в выражениях, которые я не буду здесь цитировать.
    Уж простите за резкость, но действительность очень и очень сильно отличается от атмосферы внутри госучереждений. Или Вы в банке работаете?

    • Sep 21st, 2011 at 06:08 | #33

      “С этого момента мифический РП с растопыренными пальцами в дорогом костюме садиться за компьютер и решает задачу самостоятельно. Предварительно он был послан по известному адресу в выражениях, которые я не буду здесь цитировать.”

      Вы сами понимаете что пишете? Или Вы – программист? Обычно так рассуждают программисты до поры до времени, пока не придется искать другую работу.
      Если РП набрал таких людей и так организовали процесс, что хвост рулит собакой, то грош цена такому РП. И правильно, что проект завален, он и должен быть завален с таким подходом.

      • Sep 21st, 2011 at 23:19 | #34

        Мои регалии и “этапы большого пути” Вы с легкостью найдете в ЛинкедИновском профиле, чтобы облегчить Вам задачу и удовлетворить любопытство я этим профилем и залогинился. Это к вопросу о том who am I.
        Теперь о главном – я не просто понимаю, что пишу. Я отлично отдаю себе отчет в каждом сказанном слове, более того – я описываю собственное поведение в случае, когда какой-то клоун в дорогом костюме будет пытаться (а в моем случае он, уж поверьте на слово, он может только пытаться) меня строить. Я не просто расскажу, куда ему идти, я еще дорогу в подробностях живописую.
        Далее, как Вы с легкостью можете увидеть в моем профиле, я искал работу множество раз и я отлично себе представляю, что такое ДЕЙСТВИТЕЛЬНО искать работу (в 2002 году это было сделать мягко говоря не просто), тем не менее мое мнение остается прежнем.
        И да, если вдруг сегодня мне прийдется искать работу, я думаю что справлюсь довольно быстро – в зависимости от срочности и возможности торговаться я бы сказал что от 30 минут до 14 дней.

      • Sep 21st, 2011 at 23:24 | #35

        И еще, я бы воздержался от деления на “бар” и “холопов”, “хвост” и “собаку”, “плебев” и “патрициев”. Роли в проекте предусматривают всего-лишь разные задачи, разную степень и меру ответственности, разную степень рисков и разную оплату (соразмерно ответственности и рискам). Во всем остальном руководитель проекта не менее и не более важен для проекта, нежели рядовой программист – генерал не выиграет сражение без солдат, равно как и солдаты не смогут эффективно воевать без генерала.

    • Sep 21st, 2011 at 06:14 | #36

      “Мои знания и моя полезность никак не коррелирует с моей манерой одеваться.”
      Не сочтите за упрек, это я думаю у Вас будет зона роста в ближайшем будущем :)

      • Sep 21st, 2011 at 23:27 | #37

        Да нет, что Вы, наоборот мне весьма радостно что Вы столь оптимистично оцениваете мое будущее. Я бы даже сказал что это вселяет в меня определенные надежды – я лично вижу его не столь определенным и радужным. Вы думаете, что мне предложат кресло технического директора? Это пока единственная ступенька, которая будет ростом, а не повторением и закреплением :)

    • Sep 21st, 2011 at 06:16 | #38

      “Вы не поверите, но очень часто, примерно в 40-50% случаев проблема именно в заказчике.”

      Это так только в том случае, если на проекте нет РП. Вообще нет! Потому что избежать такого положения дел – обязанность РП, на стадии предконтракта, контракта и в ходе итераций по фазам. Это одна из областей знаний по управлению проектами.

      • Sep 21st, 2011 at 23:44 | #39

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

  21. Sep 21st, 2011 at 06:05 | #40

    Коллеги, я бы для начала предложил определить причины сложившейся ситуации. Не очевидно, что заказчик гнет подрядчика просто потому что так захотелось. Так обычно делают когда подрядчик не удовлетворяет требования заказчика, неважно, сколько это стоит. Вопрос цены должен обсуждаться не с заказчиком, а со спонсором. Соответственно, заказчика нельзя прессовать ограничениями, нужно сталкивать заказчика со спонсором, самому выступать посредником возникшего конфликта интересов, а этого в проекте кейса похоже никто не делает. Причина скорее всего кроется в неправильном управлении интересами сторон и, обычно в этом случае бывает такое же никакое управление проектной командой.

  22. Sep 21st, 2011 at 13:53 | #41

    Мне “посчастливилось” работать в похожем проекте.
    В описанной стадии речь уже идет о минимизации потерь исполнителя, и как можно быстром завершении проекта. Итак по очереди:

    1) Привлечь ко всем дальнейшем переговорам со стороны исполнителя и со стороны заказчика руководителей которые реально принимают решение о финисировании и контрактах с обоих сторон. Вот тут на стороне исполнителя и должен быть человек который покажет пальцем на срок приемки в контракте, и будет его отстаивать. Встреча должна быть очной, никаких переписок и телефонов.

    2) Заново определить срок приемки (допустим 2 недели), и оговорить что все дефекты которые будут найдены в этот срок будут исправлены в рамках существующего конракта. Причем со стороны исполнителя пофиг кто и как будет искать баги, самое главное после отделять “мух от котлет”, т.е. договорится о том, что будет проведен совместный анализ найденных дефектов, чтобы отличить баг от нового требования.

    3) По истечении этого срока опять собрать людей которые подписывают контракты. И составить план работ по исправлению найденных дефектов, например оговорить, что через месяц будет новая версия, где будут исправлены все найденые баги. Исполнителю при этом нужно очень тщательно все тестировать, чтобы обеспечить оговоренное качество.

    4) Все дополнительные требования, найденные во время сдачи-приемки, не имеют никакого отношения к первоначальному контракту, даже если их требует бизнес. И это уже доп. договор. Опять же нужен крутой переговорщик, чтобы остоять это.

    Еще меня очень сильно смущает утверждение в кейсе – “Работы подрядчика не оплачиваются, т.к. контракт на поддержку можно заключить только когда система будет запущена в эксплуатацию”

    Почему нельзя оплатить контракт на выполнение работ? И при чём здесь контракт на поддержку ?

  23. Nick
    Sep 24th, 2011 at 10:04 | #42

    Возможно, мои комментарии покажутся слишком дерзкими, но тем не менее скажу. (опыт участия именно в таких проектах – штук 5. К моей радости, не в качестве РП). Сразу прошу прощения, если кого обижу – не спецом. Всё ИМХО.

    Общее мнение:
    1.1. Кейс представлен чересчур скупо и однобоко. Нет описания политической окантовки проекта, а она здесь очень сильна по факту.
    1.2. Чувствуется внутренняя обида РП – мы хорошие, а заказчик….
    1.3. Много несостыковок по описанию: заказчик бюрократичен, но проект принимается “авансом”. Подписался под двумя неделями, но не протестировал и т.п. Это как раз отсутствие оного…

    Баги РП:
    2.1. В сложившейся ситуации РП проекта по факту не имеет контакта с заказчиком. Складывается впечатление, что РП блеет как овца перед заказчиком и боится. Чего? Зачем? Дано: “заказчик ключевой”. Так почему нет понимания?
    2.2. Нет упоминания о том – что реально было сделано для устранения проблемы. Пока вижу игнор и выжидательную позицию со стороны подрядчика. Чего ждём? Доброты заказчика? Её не будет. Как говорится “ничего личного, только Бизнес” .

    “Баги” заказчика (в кавычках ибо, ИМХО, заказчиков плохих не бывает – бывают нетехнические, неконтактные и т.п.)
    3.1. Нагловат (но, учитывая п 2.1, возможно поступает вполне правильно).
    3.2. Безответственный. Возможно, из-за понимания того, что он ключевой.

    Кратко, моё видение кейса:
    Взгляд со стороны РП: проект УЖЕ убыточный, но сделать резкие движения я боюсь, т.к. могу потерять заказчика. Он – ключевой.
    Посему “сижу на попе ровно”, делаю что могу, ставлю в известность
    руководство, авось всё рассосётся.
    Взгляд со стороны заказчика: да, я не хорошо поступаю, т.к. обещал одно, но делать не успеваю. Да, у меня на это есть причины. По приоритетам – этого подрядчика я ставлю вторым (третьим или пятым). Они от меня никуда не уйдут, т.к. я их кормлю больше всех, посему ничего, потерпят, никуда не денутся. Вытерпят – молодцы, буду кормить дальше, нет – найду других (т.к. они вторые, третьи или пятые) – не велика потеря.

    Рекомендации РП:
    1. Сначала Себе признать свои ошибки уже совершённые (хотя-бы на будущее).
    2. Решить для себя – готовы ли вы потерять заказчика. Реально понять – для вас заказчик ключевой или единственный. Сможете ли вы как фирма (команда) жить без него или нет? Далее – понятно, надеюсь…
    3. Найти потерянный контакт (а судя по всему ранее он был хороший, ибо ключевой) с заказчиком. Выложить ему все карты ситуации – показать ситуацию ему с его стороны и ему же – с Вашей. Потом попросить его обязательно рассказать как он видит ситуацию. Наверняка Вы по разному смотрите на одни и те-же вещи. Найти компромисс. Не думаю, что заказчик сразу же уйдёт в игнор.
    4. п.3. проводить только лично. Минут 30 или час общения я думаю выбить из заказчика всегда можно. А одна однодневная командировка в любую точку земли будет стоить не дороже двух месячных пустых трудозатрат целой команды.

    Опыт. Такие ситуации с проектами у нас бывали (специфика направления). В большинстве случаев всё решается положительно.
    Ну как конкретный пример – все новые “хотелки” – только по отдельному договору (в пределе – на каждую). Суммы договоров покрывают по факту работы по сопровождению. Объём хотелок падает сразу в разы, ибо кроме цены – заказчик попадает в целую кутерьму бумажной рутины, и при очередной хотелке он начинает всё-таки думать, на сколько “хотелка” критична ему. Если к технике (хотелки 3,4 без 5 и 8 нереализуемы) подключать маркетинг (аля, “Если вы согласны на договор по хотелкам 3-4, то 5 и 8 мы можем сделать бесплатно, как ключевому заказчику”), то в большинстве случаев это положительно влияет как на финансовую сторону проекта, так и на отношения с заказчиком.

    Скажу сразу – реально неудачный опыт у нас был только в одном случае. Да, мы потеряли целое направление проектов. Да, заказчик потерял хорошую команду, которая отлично знала его потребности. На момент выяснения аналогичной ситуации мы оба хорошо и крепко стояли на рынке, и оба не сошлись во мнениях. И ничего страшного – каждый пошёл своей дорогой. Только бизнес.
    Справедливости ради стоит сказать, что прошло после разрушения отношений более 8 лет. И сейчас с этим заказчиком у нас снова начинаются отношения. Один стартап уже прошли. А дальше – жизнь покажет.

  24. Алексей Александров
    Sep 30th, 2011 at 17:02 | #44

    Ошибки кроме уже найденых:
    1. Длинный fix-price это уже провал. Погрешность оценки даже проекта в 6 месяцев становится слишком серьезной.
    2. Плохо установлен процесс внесения изменений в скоуп, в нормальном случае любое изменение оценивается с точки изменения импакта на проект (цена и сроки) и фиксируется с Заказчиком.
    3. Видимо, в требованиях не описано то, что в данном проекте НЕ должно делаться. Разбавлять “позитивные” требования “негативными” также может быть крайне полезна при торговле за новую функциональность.
    4. Отсутствие жестких критериев приемки и окончания тестирования, согласованных с Заказчиком.

    Выход – к описанию Nick особо добавить нечего, кроме странности в
    “заказчик довольно бюрократичен” VS “срок, указанный в этом письме, игнорируется”. В таком случае можно уже занимать более жесткую позицию, и привести для сложной системы стоимость перехода к другому вендору плюс судебные издержки. В нашей практике даже второй части бывает достаточно, чтобы Заказчик пришел к разумному компромиссу. Также фразы “не можем тестировать, система сырая” вкупе с отсутствием репортов о дефектах, могут быть хорошим пунктом при торговле (присутствует явное нарушение процедуры работы).

  25. Владимир Вознесенский
    Oct 27th, 2011 at 10:27 | #45

    Идти в суд. С бюрократами не договоришься.

Leave a comment