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

Ситуация такова:
1. формальная документация и реальное состояние продукта друг друг не соответствуют и соответствовать никогда не будут. В этом направлении проламывать стену лбом совершенно бесполезно, но можно сделать неофициальную документацию, для внутреннего использования. Это единственный способ зафиксировать состояние системы в виде "как на самом деле".
2. разработка начинается до того, как требования согласованы и зафиксированы, отсюда высокий риск изменений. Опять же - требовать согласования до начала разработки бесполезно, т.к. то, что команда не уложится в сроки, заказчика не волнует (т.е. это наши проблемы, как исполнителей).
3. отношения с заказчиком таковы, что мы должны принимать практически все его требования, возражения не принимаются, можно только влиять в некоторых пределах на способ реализации. Такова политика работы с данным заказчиком.

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

Личный опыт работы с госами особенно приветствуется

Работала с госзаказчиками. Ничего не советую, просто описываю. Те же проблемы что и у вас. Руководство договорилось об оплате по факту (сколько реально будет потрачено времени). И мы занимались экстремальным программированием. Утром требования от бизнеса...вечером код.. Нам было нормально, заказчику такой проект не понравился. Второй проект вели с нами уже "по-правильному". Первый закончили за год, второй уже года три тянется...
По п.1 не поняла. Когда не соответствует документация реальному состоянию, то это заказчик увидит в первый же день.

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

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

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

Ситуация такова:
1. формальная документация и реальное состояние продукта друг друг не соответствуют и соответствовать никогда не будут.

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

В этом направлении проламывать стену лбом совершенно бесполезно, но можно сделать неофициальную документацию, для внутреннего использования. Это единственный способ зафиксировать состояние системы в виде "как на самом деле".

2. Неофициальная документация - это требования к новому продукту (системе)?
2а.Если это попытка описать решения для старой системы, то зачем это описание решений вам необходимо и как вы реально это описание используете?

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

3. Вряд ли Вы всё-таки ведете разработку на основании требований, взятых совсем из собственной головы. Наверное, есть требования Заказчика в каком-то виде и наверное у Вас есть проблемы с их полнотой и детальностью? Есть ли возможность задавать уточняющие вопросы по требованиям Заказчику и получать ответы? Задокументированы ли эти требования хотя бы в каком-то виде (например ТЗ)? Подписан ли этот документ Заказчиком (возможно, в качестве приложения к договору)?

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

Личный опыт работы с госами особенно приветствуется

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

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

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

Видимо, Вы имеете в виду, что ТЗ у заказчика утверждает некий начальник, а работать по существу приходится с его подчиненными, у которых иные более практические интересы?
Попробуйте не неофициальную документацию писать, а "разделить" ТЗ на два уровня: на верхнем содержатся требования, понятные начальнику, на нижнем - существенные для подчиненных. Плюс некую табличку мэппинга одного уровня на другой. С кем это согласовать, Вам виднее...

А "городить рядом" гору документов по сути бессмысленно, Вам ведь сдавать работу придется по ТЗ, а не по вашим писулькам, насколько бы правильные и верные они ни были бы...

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

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

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

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

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

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

Я объясню, в чем основная сложность с документацией.
У заказчика очень тяжелый, затянутый процесс согласования документов. К моменту официального согласования может пройти столько времени, сколько требовалось на разработку половины системы - поэтому дожидаться этого момента мы не можем. Это идиотизм, но в таком режиме все равно приходится работать.

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

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

Здравствуйте, Ida!

Полностью согласен с Водолеем: нужно привлекать Заинтересованных лиц. И "манипулировать" ими. В TOGAF это называется "управление заинтересованными лицами".

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

Пример из личного опыта.

В одном из учреждений Администрации Санкт-Петербурга (Заказчик) решили разработать систему для управления своими районными филиалами и оказанием услуг в этих филиалах. В качестве базовой была принята система, уже несколько лет функционировавшая в одном из филиалов и разработанная Исполнителем.

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

Ситуация, почти как у Вас.

Есть жесткие документы, по которым невозможно сделать систему. (К счастью, в ТЗ требования были представлены на достаточно высоком уровне.)
У исполнителя не сохранилось никаких документов по старой системе, а люди уже уволились. Пришлось нанимать людей под проект.
У руководства Исполнителя единственное требование - чтобы Заказчик был доволен.

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

Удалось убедить, что требования ТЗ недостаточно конкретны, и их надо детализировать. А т.к. "детализация" - это "изменение", удалось убедить в необходимости создания и включения в перечень "неразрывно связанных с Контрактом" документа "Правила управления требованиями" (аналог плана управления требованиями RUP). Вводились правила упрощенного процесса согласования изменений требований, если они не вступают в противоречия в ТЗ.

Утвержденный ("водопадного" вида) План содержал (к счастью) этап Эскизного проектирования (все по ГОСТ!). Удалось убедить детализацию требований включить в отчет Эскизный проект (чтобы основополагающее ТЗ не менять!

И, в заключение, удалось убедить, что Заказчик заинтересован в пошаговой поставке функциональностей.

Ну, а дальше работа пошла по "нашим" правилам.
Документ под названием "Эскизный проект - общий отчет" - по шаблону RUP Vision.
Документ "Эскизный проект - Приложение №..." - это Use case Specification.

Согласование документов, быстрая реакция на замечания (документы небольшие!) увеличивало доверие.

Архитектурой заниматься почти не пришлось (модернизация старой системы), Поставки функциональностей пошли почти сразу за спецификациями.
Поставки сопровождались руководствами пользователей (отредактированные спецификации). Доверие было обеспечено. Окончательная сдача трудностей не вызвала: в филиале-полигоне система уже работала.

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

P.S. Относительно технологии управления заинтересованными лицами: если Вам лень искать это в TOGAF (на английском), Вы можете посмотреть мой опус, посвященный моделированию заинтересованных лиц: http://lnew.ucoz.ru/publ/modelirovanie_arkhitektury_predprijatija/arkhitekturnye_karkasy/modelirovanie_zainteresovannykh_lic_v_togaf/4-1-0-5

Я объясню, в чем основная сложность с документацией.
У заказчика очень тяжелый, затянутый процесс согласования документов. К моменту официального согласования может пройти столько времени, сколько требовалось на разработку половины системы - поэтому дожидаться этого момента мы не можем. Это идиотизм, но в таком режиме все равно приходится работать.

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

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

Как вариант можно предложить команде работать по SCRUM, получая на вход в бэклог реальные задачи (отдельный вопрос откуда они будут поступать), а в качестве отдельной активности делать разработку "внешней документации", которую по-сути можно постепенно приближать к реальности, при условии если нет на это ограничений. Тут еще вопрос - заказчик-то знает, что документация на систему которую ему приносят и реальная система слабо коррелируют друг с другом? Если да и приемлет это, плюс при сдаче системы это не вызовет сложностей - то можно особо не переживать. В ином случае - срочно в письменно виде нужно эскалировать проблему дирекции проекта - пусть они берут на себя риски по разруливанию ситуации, иначе крайним окажется аналитик и PM. Или просто аналитик, если PM ушлый ...

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

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

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

Далее, с этими людьми согласуется каким образом другим структурам заказчика проект будет представляться и сдаваться, проходя необходимые процедуры. Включая документацию. Соответственно, в деньги проекта должны быть заложены затраты на деятельность, связанную со сдачей и прочими орг.мероприятиями, которая обусловлена особенностями заказчика. В зависимости от конкретных условий у заказчика ее объем может доходить до 70-100% к основной работе по проекту, поэтому ее надо реально закладывать.

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

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

Всем спасибо за информацию, буду пытаться применить на практике

Всем спасибо за информацию, буду пытаться применить на практике

Удачи вам в этой непростой ситуации!

В результаты неторопливых размышлений и действий пришла к двум выводам:
1. с людьми я работать не умею
2. менеджер из меня хреновый

Ну что же, отрицательный результат тоже результат

Увы! Вы не одиноки!

В результаты неторопливых размышлений и действий пришла к двум выводам:
1. с людьми я работать не умею
2. менеджер из меня хреновый

Ну что же, отрицательный результат тоже результат

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