6 стадий проекта

← →
blackman © (2009-06-08 14:16) [0]

1. Энтузиазм
2. Крушение иллюзий
3. Паника
4. Поиски виновных
5. Наказание невиновных
6. Восхваление и награждение не участвовавших

А как у Вас?

← →
keymaster © (2009-06-08 14:25) [1]

1. Ознакомление с требованиями заказчика.
2. Составление ТЗ.
3. Планирование времени разработки
4. Разработка
5. Тестирование
6. Доработка
7. Выдача продукта заказчику.

← →
Игорь Шевченко © (2009-06-08 14:28) [2]

1. Ознакомление с требованиями заказчика
2. Создание мини-ТЗ и прототипа, тестирование прототипа
3. Ощупывание прототипа, реализация функциональности, тестирование
4. Выдача продукта заказчику
5. переход к третьему пункту

← →
BiN © (2009-06-08 14:43) [3]

> blackman © (08.06.09 14:16)

я в таких случаях бегаю.
доза эндорфинов - самое то во время стресса (т.е. в любое время))

зыж
вопрос всё ж был не по стадиям, как я понимаю?

← →
test © (2009-06-08 14:45) [4]

1 Шумиха
2 Неразбериха
3 Наказание невиновных
4 Награждение непричястных

этому бояну лет 500))

← →
Юрий Зотов © (2009-06-08 14:46) [5]

> keymaster © (08.06.09 14:25) [1]

Причем пункты 5 и 6 имеют свойство зацикливаться...
:o)

← →
Медвежонок Пятачок © (2009-06-08 14:49) [6]

7. Потеря исходников.

После этого все баги объявляются фичами а само ПО становится бессмертным. Пока какой-нибудь энтузиаст лет через пять не перепишет все заново и не перейдет к п.7

← →
TUser © (2009-06-08 14:55) [7]

1. Замысел
2. Реализация
3. Придумывание замысла, соответствующего реализации

:)

← →
blackman © (2009-06-08 15:11) [8]

Игорь Шевченко © (08.06.09 14:28) [2]
Маловато будет! Где же тестирование и исправление ошибок.
Пропущен этап демонстрации заказчику и полной переделки проекта в результате этого :)

test © (08.06.09 14:45) [4]
Боян? Возможно, но актуален и сегодня.

Юрий Зотов © (08.06.09 14:46) [5]
Вот и я об этом же. Интересно КАК правильно. Как избежать и унифицировать...

← →
oldman © (2009-06-08 15:29) [9]

> blackman © (08.06.09 15:11) [8]
> Интересно КАК правильно. Как избежать и унифицировать...

Находится в
1. Энтузиазм
как можно дольше и ни в коем случае не начинать не только кодить, а даже и обдумывать!!!

← →
test © (2009-06-08 15:49) [10]

1 Анализ исходной задачи
2 ТРП
3 ТЗ
4 Первый прототип
5 Доводка прототипа
6 Проверка у заказчика
6.1 неудача пункт 5
6.2 удача Поддержка программы

← →
oldman © (2009-06-08 15:59) [11]

> test © (08.06.09 15:49) [10]
> 6.2 удача Поддержка программы

"Не бывает!" (Понедельник начинается в субботу ©)

← →
blackman © (2009-06-08 16:04) [12]

oldman © (08.06.09 15:29) [9]
Т.е. не показывать заказчику и не заканчивать проект никогда? :)

test © (08.06.09 15:49) [10]
Пунк 6.1 и 6.2 как различаешь? Т.е. когда удача?
Проблема обычно в том, что желания заказчика и понимание их разработчиком обычно не совпадают сразу...
Хотелось бы услышать что-то о формализации этого процесса, что бы исключить лишние goto на пункт 5

← →
Игорь Шевченко © (2009-06-08 16:20) [13]

blackman © (08.06.09 15:11) [8]

Тестирование в пунктах 2 и 3, а ошибки... Какие еще ошибки ? :)

> Пропущен этап демонстрации заказчику и полной переделки
> проекта в результате этого :)

Тебе Windows демонстрировали и после демонстрации переделывали ?
Вот и у бабочек то же самое...:)

← →
blackman © (2009-06-08 16:36) [14]

Тестирование в пунктах 2 и 3, а ошибки... Какие еще ошибки ?
Большие и маленькие :)
Про бабочек не надо :) Давай о наших

← →
oldman © (2009-06-08 16:39) [15]

> blackman © (08.06.09 16:36) [14]
> Про бабочек не надо :)

Обязательно надо!!!!!!!!!!!!!!!!

← →
Игорь Шевченко © (2009-06-08 16:39) [16]

blackman © (08.06.09 16:36) [14]

> Большие и маленькие :)

Больших нет, мелкие на этапе тестирования отлавливаются.

А к тому, что заказчик скажет, "эта не хочу, та хочу" - это утопия :)

← →
oldman © (2009-06-08 16:41) [17]

> Игорь Шевченко © (08.06.09 16:39) [16]
> А к тому, что заказчик скажет, "эта не хочу, та хочу" -
> это утопия :)

Да ну? Еще как скажет!

← →
test © (2009-06-08 16:42) [18]

blackman © (08.06.09 16:04) [12]

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

← →
Юрий Зотов © (2009-06-08 16:46) [19]

> blackman © (08.06.09 15:11) [8]

> Как избежать и унифицировать...

Сие есть великая и никем непознанная тайна мироздания...
:o)

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

Правда, способ этот скорее теоретический. На практике такого не встречал.
:o)

← →
Игорь Шевченко © (2009-06-08 16:46) [20]

oldman © (08.06.09 16:41) [17]

Значит, все еще впереди.

← →
blackman © (2009-06-08 17:06) [21]

Игорь Шевченко © (08.06.09 16:39) [16]
Больших нет, мелкие на этапе тестирования отлавливаются.
Маленькие, но неприятные :)
Помнишь анекдот про маленькую птичку из Африки, размером гораздо меньше колибри? :)
А к тому, что заказчик скажет, "эта не хочу, та хочу" - это утопия :)
Это жизнь. Вопрос как уберечься от его притязаний. Ограничить не оговоренное ранее.

Юрий Зотов © (08.06.09 16:46) [19]
Есть один способ - не давать заказчику беконечно изменять требования к проекту. То есть, заставлять его подписывать ТЗ и сдавать этап проекта строго в рамках этого ТЗ, относя все придуманные заказчиком бантики и рюшечки на следующий этап (на который тоже должно быть подписанное заказчиком ТЗ).
Правда, способ этот скорее теоретический. На практике такого не встречал.
А как же вы с ними боретесь? Есть же какие-то приемы? ДЖИУ-ДЖИТСУ БОЕВАЯ САМООБОРОНА ? :)

← →
ANB (2009-06-08 17:07) [22]

> 1. Энтузиазм
> 2. Крушение иллюзий
> 3. Паника
> 4. Поиски виновных
> 5. Наказание невиновных
> 6. Восхваление и награждение не участвовавших
>
> А как у Вас?

У нас первые 6 пунктов, а затем :
+
7. Передача разработки к нам в отдел (обычно первые 6 пунктов на оутсорсе)
8. Много мата по поводу выполненной реализации
9. Подключение юзеров и аналитиков, чтобы выяснить, а что же таки юзеры хотели.
10. Составление требований, согласование с программистами, а можно ли их технически реализовать малой кровью
11. Составление ТЗ на разработку.
12. Реализация.
13. Тестирование на юзерах.
14. Доделка (цикл на п.13, пока более менее не будет пригодно к работе. В случае зацикливание - привлечение административного ресурса. Обычно в течение 15 минут юзеров начинает все устраивать :) )
15. Установка на продуктив.
16. Переход на п.13. Но доработки уже по отдельным заявкам (а сами хреново проверяли - а акты у нас все подписаны :) ).
Примерно через полгода пилота процесс устаканивается и все работает. Периодические маты, когда вылезают недоделки п.1 и приходится править.
:)

← →
ANB (2009-06-08 17:10) [23]

Забыл :
17. Примерно через год вырастают объемы, написанная система "ложиться" и все переписывается. Главное - требования уже есть, проверять можно по принципу "чтобы работало точно также, только быстрее и не падало".

:)

← →
Игорь Шевченко © (2009-06-08 17:11) [24]

blackman © (08.06.09 17:06) [21]

> Это жизнь. Вопрос как уберечься от его притязаний. Ограничить
> не оговоренное ранее.

Нет проблем, хотите нового - платите

← →
blackman © (2009-06-08 17:22) [25]

ANB
Это если внутри организации. В основном перепалки между отделами...
Интересно, что там может быть такое в ТЗ. Все не напишешь и не учтешь.
А есть какие-то обязательные пункты?

← →
blackman © (2009-06-08 17:23) [26]

Игорь Шевченко © (08.06.09 17:11) [24]
Нет проблем, хотите нового - платите
Обычно отвечают, что это они и раньше хотели, а вы просто не поняли и не сделали. И как доказать ?

← →
Игорь Шевченко © (2009-06-08 17:35) [27]

blackman © (08.06.09 17:23) [26]

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

← →
ANB (2009-06-08 17:48) [28]

> Интересно, что там может быть такое в ТЗ. Все не напишешь
> и не учтешь.

Качество ТЗ зависит от аналитика.
Чем подробнее в нем прописано, что надо сделать - тем легче потом всем жить.
Плюс есть подпись заказчика на ТЗ - всегда мона потыкать носом.

Хотя как раз внутри организации это не всегда помогает - денег то за разработку заказчик вроде как не платит. Есть юзеры, которые подписывают ТЗ не читая, а потом говорят, что все сделано не так, как хотели.
Таких воспитываем снижением приоритета и подключением админ.ресурса.

Игорь Шевченко © (08.06.09 17:35) [27]
Видимо есть специфика какая-то. Типа только для самолетов?

ANB
Качество ТЗ зависит от аналитика.
А аналитик от чего ? :)

> blackman © (08.06.09 17:57) [29]

> А аналитик от чего ?

От мозгов и опыта. "Бойцовый Кот есть боевая единица сама в себе".
:o)

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

Через некоторое время приходит мне другое ТЗ, от другого аналитика. Читаю - класс! Высший пилотаж, натурально. Восхищение и аплодисменты! И тут пришло мне в голову проверить - а что, в этой конторе всегда можно от ТЗ отступать, или нет? Говорю шефу (а он и это ТЗ тоже не смотрел) - тут вот ТЗ пришло. Он (опять моментально и опять не отрываясь от клавы) - кто ТЗ писал? Такой-то, говорю. Отвечает - Юрий Сергеевич, тогда делайте строго, как написано.

:o)

Игорь Шевченко © (08.06.09 17:58) [30]
Да, причем, в комплекте с авианосцем
Это уже будет типа только для авианосцев :)

Юрий Зотов © (08.06.09 18:15) [31]
От мозгов и опыта. "Бойцовый Кот есть боевая единица сама в себе".
Логично. Не верю я, что могут существовать "суперлюди" которые помогут программисту.

Boriskb.narod.ru/project.jpg
Года два назад я эту картинку публиковал.
Позволю себе побоянить :)

Cемь.
Семь стадий проекта:

1. Искушение, т.е. заманчивость задачи. Льстит самолюбию, и ваще... И вот это ещё кому-то интересно?
И за это ещё деньги платят?

2. Не то, чтобы энтузиазм, а, скорее, способ заработать деньги на том, что ещё знаешь и умеешь.

3. Синтетически называется неопределённым глаголом "наткнулся". Простую задачу не предложат.

4. Ну, паника - хорошее слово. Но не паника, а растерянность, неуспевание в сроках, неуверенность, негатив.

5. Преодоление паники. Сосредоточение. Первые результаты. Первые успехи. Уверенность в силах.

6. Ненависть к проджекту! Открывание и просто ненависть. Постепенное преодоление таковой.

7. Более или менее убогий, но подходящий результат. Заказчик и такого не ожидал.
Подрядчик не ожидал, что и такой сойдёт. Оба сходятся, что надо доработать.
Оба считают, что достигли цели.
Всеобщее Благорастворение воздухов.
И Заказчик, и Подрядчик - оба отчитаются перед начальством.

Хэппи;
End.

На самом деле число 7 обладает удивительным и гармоническим свойством:
семь нот, семь цветов, семь дней недели.

Его не зря называют "счастливым": десятеричная десятка в семиричной системе - это 13.
А очко (21) - это 30 :))

Все знают, как построить 5-ти и 6-ти конечные пентаграмму, гексаграмму - 360 делится и на 5, и на 6.
Но строят и септаграмму, хотя нацело и не делится.

Я бы советовал любую деятельность делить на 7 этапов.
Иррациональность деления двух пи на семь подразумевает и непредсказуемость результата.
Тогда вместо уныния появляется надежда.

> Юрий Зотов © (08.06.09 14:46) [5]
> > keymaster © (08.06.09 14:25) [1]Причем пункты 5 и 6
> имеют свойство зацикливаться... :o)

о, да =)

Счастливые люди. У них даже есть ТЗ...

про откаты уже было?

6 стадий проекта Найти похожие ветки