Project management (rus), Requirement management (rus)

ЛАФ11. Я. Могут ли быть выгодны ошибки аналитика или история одного тендера

На основании данной статьи я готовил свое выступление на ЛАФ’11.

 Введение. Мы все ошибаемся

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

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

Любопытно следующее – со временем выяснилось, что ошибки могут повлечь за собой не только отрицательные, но и положительные последствия и принести компании прибыль. Каким образом? Об этом и пойдёт речь в настоящей статье.

Предпосылки ошибок и ответственные за них. Тендеры и прибыль

Итак, если аналитик ошибся, то его ошибки зафиксированы в Техническом задании или постановке на реализацию (так как, если говорить о ГОСТе, это конечные документы, на основании которых ведется разработка). Но, возвращаясь к анализу источников ошибок и ответственных за них, хочется задать вопрос: только ли аналитик виноват в том, что эти ошибки возникли? Я считаю, что нет, и предпосылки для ошибок возникают в самом начале проекта, при попытке компании выиграть тендер. Замечу, что под ошибками я не подразумеваю риски, так как риск это то, о чем мы знаем.с

На всякий случай поясню:

● Тендер – (от англ. tender – торги, конкурс) прямое заимствование из английского языка, используемое для обозначения торгов, конкурсов.

Существует открытый и закрытый вид тендера. При открытом тендере участие в конкурсе могут принимать любые желающие. Закрытый тендер подразумевает ограниченный круг участников.

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

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

1. Участвуйте в тендерах.

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

2. Выбирайте конкурс или аукцион в соответствии со своими финансовыми возможностями.

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

Любопытный случай из практики. Запрос на изменение иногда может выглядеть несколько необычно, например: пользователь должен силой разума переносить файлы в архив. В итоге, достаточно было реализовать кнопку “Перенести в архив”.

Второй момент – нужно оценивать стоимостные предложения конкурентов и внимательно оценивать не уйдёт ли компания в убыток по итогам проекта.

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

4. Если вам незаконно отказано в участии или праве исполнения контракта, смело подавайте жалобу в ФАС (Федеральная антимонопольная служба), не забыв при этом указать в ней все необходимые сведения.

В представленном выше списке наиболее интересны пункты 2 и 3 – они наиболее сильно влияли на работу аналитика, так как компания начинает резко уменьшать сроки реализации и стоимость проекта, обещая реализовать качественную систему.

Категории компаний, участвующих в тендере

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

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

● Остальные или интересные компании для подтверждения гипотезы. Эти компании хотят выиграть тендер практически любой ценой и ограничиваются лишь здравым смыслом. Отсюда я назову их – Наглые компании или Наглецы.

Здесь необходимо добавить новое ограничение: речь идет не о проекте из 5 табличек в базе данных (то есть, мы говорим не о маленьком проекте).

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

Введу некоторую величину N, отражающую степень «наглости» компании при проведении тендера и колеблющуюся в промежутке от 0 до 1 (чем ниже N – тем наглее компания). Получаем, что при фиксированном качестве Итоговые сроки = Заложенные в тендере сроки *N, Итоговая стоимость = Заложенная в тендере стоимость *N.

Казалось бы, причём тут мы, аналитики, если за успешность проекта, в целом, отвечает его руководитель? Ответ следующий:

1. Писать ТЗ по формуле Время на написание ТЗ=Реальные сроки*N приходится нам. Для аналитика величина N отражает количество его переработок, которое потребуется, чтобы написать ТЗ в срок. Таким образом, N отражает снижение величины премии аналитиков, но чем выше N, тем выше вероятность выиграть тендер.

2.Написать требование на основании строки из ТКП «Система должна согласовывать изменение показателей у всех заинтересованных лиц» дабы заказчик сразу подписал и проект не вылететь по срокам, впоследствии выяснить, что не было учтено требование второго заинтересованного лица (на личный разговор с которым не хватило времени и аналитик доверился словам руководителя проекта о том, что их мнения совпадают), а для закрытия проекта требуется написанное нами ЧТЗ и доработки – тоже наша задача.

3.Прибавим сюда наём сторонних разработчиков (субподрядчиков) и “зелёных” студентов, чтобы как-то компенсировать уменьшение бюджета проекта. Например, рассмотрим некоторую абстрактную ситуацию:

В день мы можем потратить на разработчиков 1800 рублей (возьму несколько абстрактные цифры). Использовать своих разработчиков нам не по карману, каждый из них требует 300 р/час и их потребуется двое. Если нанимать субподрядчиков, то это будет 200 р/час, то есть Затраты за день = 2*8*200 =3200 руб. Нанимаем студентов за 50 р/час, обещаем им практику и рекомендации, в случае успешно выполненной работы, в итоге получаем 2*8*50=800 рублей в день, а, для надежности нанимаем своего разработчика в качестве консультанта на 2 часа в день 2*300=600 рублей. Следовательно, мы получаем 400 рублей прибыли в день. Ситуация тут следующая – ошибаются как аналитики, так и разработчики, но опытный разработчик может обнаружить некоторые ошибки аналитика, да и сам по себе ошибается реже.

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

Следствие. На чем сэкономили и что получили в итоге

Что же мы видим в итоге? Зачастую картина такова: проект пора сдавать, а он готов лишь на (100*N)%, а может и (100*N/2).

Ответ на вопрос «Что делать?» также вполне ясен – уговорить сдать основной функционал в срок, а потом дописывать систему (следует отметить, что это является распространенной практикой и у Фаворитов). Но, по мере снижения ошибок «system error» и повышения ошибок «Это не то, что я задумывал, это не поддерживает мой бизнес процесс!», на свет появляются ошибки написанного ТЗ, а именно:

1. Указали в одном месте, что система выполняет определенные функции сама по себе и забыли об этом. Подобной проблемы ещё можно избежать, если ТЗ составляет один человек, описывая при этом и сценарии использования. Если же это текстовый формат, содержащий обилие прототипов, а пишет его около 5 аналитиков, то за неделю до окончания проекта вполне вероятно обнаружение фразы, содержащей слово «автоматически» (например, «Период голосования привилегированных акций определяется автоматически»).

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

3. Прототип противоречит текстовому описанию, а текстовое описание – прототипу. Дополнительно может возникнуть противоречие действующему законодательству – очень важный момент, так как ни в одном документе не указано, что система должна соответствовать ТЗ, не учитывая изменения в законодательстве.

И это лишь несколько проблем, из тех, что могут возникнуть.

Далее руководство поднимает вопрос «кто виноват?» – обычно это аналитик, или, из вежливости перед сотрудником, заказчик. Хотя руководство чаще всего понимает, что всему виной пресловутое N, но признавая данный факт, руководитель берёт ответственность на себя, а это происходит крайне редко. Как бы то ни было, время идёт, проект выходит за рамки бюджета, выплаты сдвигаются, заказчик начинает предъявлять претензии, в том числе финансового характера. В подобных случаях на проект пытаются перевести дополнительные ресурсы (что, впрочем, не исправляет ситуации), ошибки, противоречия в ТЗ всё так же пытаются сдвинуть на поддержку и т.д.

Исключение. Когда ошибки могут принести пользу?

Итак, мы к главному вопросу: могут ли допущенные ошибки быть полезными и хотя бы иногда помогать компании? Ответ – да, в следующих случаях:

1. Заказчик решит доработать систему. Учитывая, что заказать доработку у другого подрядчика будет достаточно тяжело – придётся разбирать, проектную документацию, которая может не отличаться корректностью, да ещё и быть дополненной перепиской аналитика и заказчика по почте. Здесь ошибки/недочёты аналитиков, в условиях ограниченного времени на упорядочивание требований, могут сыграть на руку той компании, которая изначально вела разработку. Я не рассматриваю вариант, что ошибок было слишком много, чтобы заказчик не хотел видеть кампанию победителем тендера, а так же то, что ошибки были заложены специально. Лично я пока о таком не слышал. То есть следствием будет то, что заказчик, если все-таки решится дорабатывать систему, никуда не денется.

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

Здесь возникают новые ограничения, связанные с обнаружением заказчиком ошибок в ТЗ:

1. Заказчик их не заметил до подписания ТЗ.

2. Заказчик их заметил, но не смог доказать, что это требование просто в ТЗ двояко трактовалось, а аналитик реализовал на своё усмотрение.

3. Заказчик не может продуктивно работать с системой (либо не может достигнуть поставленной цели), пока не будет изменен данный функционал.

4. Заказчик не передумал с вами работать.

5. Заказчик имеет деньги на необходимые доработки.

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

Вывод. Не следует преднамеренно ошибаться

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

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

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

Примечание. Конечно же, не только плохое ТЗ может быть причиной провала, однако здесь я рассматривал ошибки аналитика – ошибки архитектора баз данных, разработчиков или тестировщиков я лишь косвенно упоминал.

Advertisements
Standard

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s