|
Роман Лебедев | 25 февраля 2015 г., 09:20 |
Борис Зверев | 25 февраля 2015 г., 13:18 |
Роман Лебедев | 25 февраля 2015 г., 14:00 |
Борис Зверев | 25 февраля 2015 г., 20:36 |
Три варианта - да, это личный опыт плюс проанализированный чужой опыт, но изначально (смутные воспоминания из студенческих времён, сейчас уже не скажу точно, откуда - кажется, в рамках предмета "организация производства" что-то такое встречалось) были даже какие-то математические выкладки из области теории вероятности и статистики. Можно "погуглить в яндексе" - наверняка найдётся.
По поводу этапности. Позволю себе цитату из упомянутого мной ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания":
Стадии | Этапы работ |
1. Формирование требований к АС | 1.1. Обследование объекта и обоснование необходимости создания АС. 1.2. Формирование требований пользователя к АС. 1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания) |
2. Разработка концепции АС. | 2.1. Изучение объекта. 2.2. Проведение необходимых научно-исследовательских работ. 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя. 2.4. Оформление отчёта о выполненной работе. |
3. Техническое задание. | Разработка и утверждение технического задания на создание АС. |
4. Эскизный проект. | 4.1. Разработка предварительных проектных решений по системе и её частям. 4.2. Разработка документации на АС и её части. |
5. Технический проект. | 5.1. Разработка проектных решений по системе и её частям. 5.2. Разработка документации на АС и её части. 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку. 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации. |
6. Рабочая документация. | 6.1. Разработка рабочей документации на систему и её части. 6.2. Разработка или адаптация программ. |
7. Ввод в действие. | 7.1. Подготовка объекта автоматизации к вводу АС в действие. 7.2. Подготовка персонала. 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями). 7.4. Строительно-монтажные работы. 7.5. Пусконаладочные работы. 7.6. Проведение предварительных испытаний. 7.7. Проведение опытной эксплуатации. 7.8. Проведение приёмочных испытаний. |
8. Сопровождение АС | 8.1. Выполнение работ в соответствии с гарантийными обязательствами. 8.2. Послегарантийное обслуживание. |
Как видите, разработка Технического задания идёт не ДО проекта, а лишь на третьей стадии. Часто по разным причинам (по каким - тема отдельная) от этого отходят, что приводит к проблемам. Главная причина проблем - неопределённость требований (условий, ограничений) к конечному результату проекта, из-за чего сложно (а порой и невозможно) оценить состав задач, объём работ, их длительность, трудоёмкость, требуемые ресурсы, стоимость и т.д.
Как выглядит водопад - это не один большой "плюх", а каскад, ступеньки. В пределах "ступеньки" - те самые итерации. Как только подошёл к краю ступеньки и шагнул - всё, ушёл на следующий этап.
По каждому этапу может быть определена своя "точка невозврата", после которой нужно двигаться строго вперёд, но нельзя вернуться "малой кровью": возврат должен означать возврат на исходную позицию. А уж чей "косяк" тому виной - тот и платит; если это техническая/технологическая ошибка исполнителя, то платит он, если новая внезапная "хотелка" заказчика - то заказчик. При этом, в большинстве случаев, управленческий "косяк" исполнителя тоже оплачивается исполнителем. (грешат этим иногда МП и продавцы, стремясь угодить клиенту, сэкономить или просто по незнанию - тут без ГИП их к телу заказчика допускать опасно, чтобы на нереализуемые вообще или в рамках бюджета/сроков проекта "фишки" не подписались). Похоже всё это в итоге на водопад - коли уж вода прошла порог и падает вниз, уже не остановишь, и с нижнего уровня наверх просто так не вернуться (даже график где-то такой есть, описывающий суть подхода) - только насосом за счёт того, кто эту воду хочет поднять :) Или как спуск с горы на горных лыжах. Или американские горки. В общем, аналогов много.
Так вот, этой точкой невозврата по каждому крупному этапу должен быть некий результат, являющийся основой для дальнейших работ (следующего этапа). Стены - на фундамент. Крышу - на стены. И т.д.
Вот Вы привели пример, что "сдвигали перегородки". Это и есть пример плохой проработки - потому что изначально не были собраны (и не уточнены в процессе разработки, но до монтажа) все требования (включая требования/пожелания потенциальных пользователей/потребителей продукта - чтобы перегородка изначально была поставлена там, где нужно заказчику или будущему пользователю), либо в процессе выполнения проекта они поменялись.
Ну, что касается изменения требований/пожеланий в процессе выполнения проекта, это уже немного другая тема. В идеале такого быть не должно: для этого и проводятся обследования и согласования с подписанием формальных промежуточных документов - в т.ч. и для того, чтобы заказчик понимал, что изменения согласованных требований повлекут как минимум дополнительные затраты времени/денег/ресурсов, а как максимум - окажутся невозможными. Конечно, могут поменяться внешние условия (законодательство, нормативы, обстановка, климат, ... и т.д.), и на них имеет смысл закладываться в виде рисков и подстраховываться в тексте договора. Конечно, не всегда сразу можно предугадать/предусмотреть/формализовать всё.
Но тут должен быть разумный предел. Во-первых, некое дробление на этапы с заранее заложенным в план уточнением деталей. Во-вторых, можно (и нужно) оставить некий запас свободы (погрешность) на непредвиденные обстоятельства. Обычно я закладываю 15-20% трудоёмкости/сроков/цены. Ну и в-третьих, как учат нас классики технического писательства, "если в ТЗ должно быть приведено требование, но оно не определено на момент написания ТЗ или не предъявляется вообще - так и надо написать: будет уточнено на этапе ... или не предъявляется".
А если грамотно и подробно составлена контрактная часть (договор, ТЗ, календарный план) - не стесняйтесь отбиваться от заказчика. "А вот нам бы еще хотелось, чтобы вы нам вот тут вот так вот сделали" - не надо сразу исполнять. Если видно, что почти бескровно (в пределах тех 15-20%, о которых я говорил) можно, то сделайте, конечно, для налаживания добрых отношений с заказчиком (пригодится при приёмке или на будущих проектах ;)), но зафиксируйте письменно изменение. Если же не укладываетесь в заложенный рисковый запас - отказывайтесь, и если клиент настаивает, делайте новый план (обязательно проверив реализуемость и влияние нового требования на остальную часть работы, прежде всего - уже выполненную).
Ну вот, опять "многобукафф".
Роман Лебедев | 10 июня 2015 г., 06:34 |