О, какой интересный топег, а я и не поучаствовал
У меня есть несколько вопросов к отдельным высказываниям учаснегов.
1.
whirlwind
Вот это бы я послушал с удовольствием. Хочется убедиться, что ПМ и разраб могут уживаться в одном человеке без ущерба для обоих процессов. Судя по вакансии, такие люди реально встречаются.
Как можно судить о существовании определенных людей по пустующей вакансии? Ведь не все человеческие желания реально осуществимы
2.
Sherman
1. Business Vision - зачем багтракер вообще, какие задачи решает.
2. FSR - Функциональные требования. Самый толстый документ. В нем подробно описывается функционал.
3. UI Requirements. - User Interface (делается на основе FSR и пожеланий юзеров).
Я в этом деле дилетант-самоучка, но, мне кажется, здесь пропущен один из важнейших пунктов, который нельзя напрямую отнести к п. 2, это п. 1.5 - Схема предметной модели, над которой собственно и описан функционал п.2. То есть, если грубо на реальном примере, в большинстве случаев это структура БД, в которой отражены сущности автоматизируемых процессов - пользователи, документы, товары... Мне кажется, проще начинать именно с этой составляющей, потом уже функционал, потом конкретные роли в системе (администратор, бухгалтер, менеджер) и уже как вершина этой пирамиды проектирования - собственно п.3 - интерфейсы, ведущий уже к конечному виду продукта (без учета тестирования и развёртывания)
3.
The employer
Я же употребил это слово (и это ясно из контекста, из самой постановке вопроса о списке рисков) в смысле определения, например, из Энциклопедического словаря экономики и права:
Отличный пример того, что ответственность за оценку производственных рисков должна решать не на разработчиках
-~{}~ 05.09.09 22:33:
4.
atv
Я недавно работал с командой над очень объёмным проектом (макроэкономика, финансы, валюты, рынки и капец ещё сколько), который с успехом провалился. Причин было много, в том числе и со стороны заказчика. Но даже если бы заказчик был идеальный, мы бы его всё равно провалили. Теперь то я понимаю многие ошибки (хотя я был рядовым програмером), но какой ценой...
Например, управление требованиями. Казалось бы, а что тут управлять. А вот, блин, влипли. Со стороны заказчика было несколько специалистов предметной области. Все переговоры велись по аське (хоть какое-то документирование ). В результате, один говорит одно, сделали, отдали посмотреть, другой сказал другое, исправили, опять отдали посмотреть (через месяц, так как раньше не соизволили), возникает вопрос, а чего так сделали?, так как сказали, кто сказал?, а хрен его знает, кто-то из вас, пошли шариться по аське (песня за кадром: а время, а время, не убавляет ход, а время, а время идёт).
А можно огласить список документации этого проекта, ну и в двух словах по каждому пункту этого списка - что это представляло собой на практике.
5.
The employer
Сбор и анализ требований - сфера компетенции разработчика, это мое глубокое убеждение. Если эту работу делает кто-то другой, разработчик в такой ситуации выступает всего лишь кодером. Никакого риска, никакой ответствености, никаких денег, никакого роста.
Мне кажется эта фраза полностью объясняет позицию докладчика касательно объединения должностей ПМа и ведущего разработчика.
Человек-оркестр может надеяться на лучшую зарплату. (Хотя, в действительно прагматичных конторах зарплата не суммируется по сочетаемым должностям, а выводится среднее, согласно доли потраченных часов на ту или иную обязанность).
-~{}~ 05.09.09 22:52:
6.
Sherman
Про итерации чуть подробнее.
Я имею в виду итерации n+1. То есть вот запустили проект - и далее вкатываемся в циклы. На моей новой работе, у нас бывают итерации вообще по неделе.
В обощем, с итерациями тут немного сложнее. Рамки итераций обычно ограничены с одной стороны бизнесом(нельзя выпускать релиз 1.2 без фитчи Х) и с другой планированием(я считаю, что _подробное_ планирование более, чем а месяц - это пустая трата времени).
Если "давит" бизнес, то можно устраивать внутренние релизы. То есть все то же самое, что и при обычном релизе, но выкладки на продакшин не происходит.
Про первую итерацию. Здесь опять же можно делать внутренние релизы и презентации, если Высокое начальство требует отчета.
Если же команда проверена, то пусть работают спокойно до первого релиза. Подробное планирование, делается в каждом месяце на следующий при такой схеме.
Разговоры об итерациях n+1 это утрированно по сути разговоры о
сопровождении и рефаткторинге, а не разработке. Потому как самую большую проблему вызывает именно первая итерация, ведущая к получению рабочего продукта (ведь суть идеалогии итерационного подхода - мы получаем рабочий продукт в результате каждой итерации, пусть и не полностью удовлетворяющей требованиям к функционалу). Проблема этой итерации, на мой взгляд, состоит в том, что оценить её стоимость в человекочасах значительно сложнее, чем стоимость последующих итераций. Ведь как она включает себя "стратегическую" часть, назовём её нулевой итерацией - это сбор требований к системе, составление первичного варианта ТЗ для архитектора, проектирования - планирование общего вида архитектуры. Ведь эти работы тоже должны быть оплачены заказчиком, а значит мы должны назвать ему конкретные сроки. С другой стороны, без успешно проведенной нулевой итерации наши сроки будут взяты с потолка. Как же быть? Опять же, об оценке сроков - расписать весь проект до уровня каждодневных работ для самого последнего верстальщика - означает выполнить как минимум 2/3 проекта, ибо когда уже полностью известен план работ - остаётся лишь воплотить конкретную идею в код. Таким образом, получается, что для точной оценки сроков мы должны выполнить большую часть работы по проекту, потратив большую часть этих самых сроков.
А ведь для действительно крупных проектов первая итерация подразумевается как значительно более крупная, нежели остальные, так ведь? То есть именно она наиболее опасна срывами сроков и прочими бедами. Когда на руках уже рабочий, пусть и не готовый продукт - дело идёт куда проще.
Есть стоимость часа работы, есть длительность итерации, следовательно стоимость 1 итерации заказчику известна сразу. Остается ознакомиться с предметной областью и разбить фронт работ на итерации ПРИМЕРНО. Предмет автоматизации на следующую итерацию выбирает заказчик - он выбирает что ему важнее с точки зрения автоматизации. Если он не может выбрать, значит автоматизация ему нужна так себе и он смутно представляет что он хочет. Но если платит, то можно и за него пофантазировать 
