Здравствуйте, Сергей Валерьевич!

По одной из ссылок я вышел на это обсуждение и был весьма заинтересован развёрнутой дискуссией. Судя по датам, много "воды утекло" с тех пор, но заданные вопросы остаются и, скорее всего, ещё долго будут оставаться актуальными. В своём последнем сообщении Максиму Болотному Вы пишете: "...Это обсуждение на Форуме пусть пока "отдохнет". Ибо, неизбежно будет общение по E-mail и личные встречи (учитывая, что мы живем в одном городе). Однако, то, что получится - выложим на сайт. И в надлежащий момент дадим здесь ссылку".

Поскольку ссылок до сих пор не обнаруживается, хотелось бы узнать, к чему Вы с Максимом в конце концов пришли? Спрашиваю об этом, в первую очередь, потому, что, на мой взгляд, в процессе дискуссии вы ушли от обсуждения основной проблемы - методов нормирования и оценки результативности труда участников проектных команд в IT-отделах, к непродуктивному обмену мнениями по вопросу принципиальной возможности и целесообразности применения подобной методики в процессе создания ПО. Я сейчас занят решением аналогичной задачи и заинтересован в открытом обсуждении практических аспектов.

С уважением, Александр.

Здравствуйте, Александр!

Я сейчас занят решением аналогичной задачи и заинтересован в открытом обсуждении практических аспектов.

1. Я думаю более приближена к Вашей ситуации вот эта тема.

2. Касательно данного обсуждения. Я не считаю обмен мнениями по вопросу принципиальной возможности и целесообразности применения подобной методики в процессе создания ПО непродуктивным.

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

Более того, именно для иллюстрации такой возможности (в том числе, для решения творческих задач) пришлось поставлять "примеры в студию", как того потребовал Максим.

• Ведь о нормировании и результативности я написал здесь.
• В ответ на что (не отрицая возможности формализации обычных процессов) Максим потребовал (цитирую) примеры творческих (нетехнологичных?) работах, пусть не программирование, пусть дизайн, музыка, реклама наконец. Пожалуйста, при приведении примеров, укажите пункты, которые они иллюстрируют.
• Я ответил здесь. На мой взгляд нормально.

И хоть потом Максим так и не прислал мне примеров, примеры в студию доставлены были и продолжают доставляться.

Смотрите публикации С.В. Сычева и К.А. Лебедева:

• "ТStupid или Новейший Органон"
• Что увидишь, то и неси
• Неважно, где рисовать
• Пусть само проявится
• ........ будет еще .............

• "Как вспомнить и так известное"
• "Освобождение узников оператора IF"
• "О потерянном уровне"
• ........ будет еще .............

3. Касательно практических аспектов. Задайте Ваш конкретный вопрос. Буду рад ответить.

Спасибо,

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

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

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

2. Бесспорно, сама по себе дискуссия о целесообразности формализации процесса разработки ПО очень важна, если у одной из сторон есть сомнения по этому поводу. Я же имел в виду то, что если в данном обсуждениии заявлена тема "Помогите составить систему мотивации для программиста!", то в процессе дискуссии с Максимом приблизиться к решению не удалось. Я полностью согласен с Вашей аргументацией в этом обсуждении и полагаю, что если оно закончилось именно таким образом, то "шарик" на стороне Вашего оппонента. Спасибо за указание на аналогичные обсуждения, действительно, я уже сравнительно давно заметил, что проблемы и "отмазки" типичны, как для указанных Вами обсуждений, так и для моего практического опыта.

3. С рекомендованными Вами статьями я ознакомился, но и они, на мой взгляд, также связаны с методами решения задач программирования, но не с управлением проектами. В этом смысле мне в своё время очень понравилась рекомендованная на вашем сайте статья "Правильные бизнес-процессы для гениев программирования". Мой вопрос заключается в следующем: каким образом можно корректно измерить результативность каждого участника проектной команды? Или, другими словами, что можно и нужно использовать в качестве эталонов применительно к процессам создания ПО?

Если необходимо дать какие-либо дополнительные разъяснения, я готов это сделать по вашему запросу.

С уважением,

Александр.

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

Вы поняли меня абсолютно верно. Ваши рекомендации по критериям оценки результативности мне понятны. Однако, пока не всё ясно с их практическим применением. Для начала мне хотелось бы привести цитату из книги "Мифический человеко-месяц" Брукса:

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

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

Однако, Ваши рекомендации внушают оптимизм. Если можно разбить любой этап проекта на отдельные составляющие с длительностью в несколько часов, то, вероятно, можно оценить и выполнение по каждой из этих составляющих. Практческое применение такого метода для оценки результативности труда тестера или технического писателя представляется вполне возможным. Но как быть с другими участниками проекта, такими как бизнес-аналитики и программисты? Я думаю, что многое прояснится, если Вы приведёте пример возможного описания реального проекта с детализацией  этапы проекта (последовательность работ "от начала и до конца") с заданным шагом, например, в 2 часа. Думаю, что будет достаточно примера всего лишь одного этапа, например, "Разработка эскизного проекта". Сразу оговорюсь, эта просьба связана не с моими сомнениями в возможности такой детализации, а с уверенностью в том, что наши руководители проектов не готовы к ответу на этот вопрос.

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

С уважением,

Александр.

Уважаемый Александр!

Добавлю деталировки к примеру Кирилла (как это делается у нас в компании). Обратите внимание на деталировку по русски в примере N.

Задача 1	Нормативное время, мин	Что на выходе
Написать техническое задание	300 (5 часов)	ТЗ по стандарту (указать)
Введение, основание и назначение разработки	30	Раздел по стандарту (указать)
Описание функциональных требований	30	Раздел по стандарту (указать)
Описание первичных требований к структуре данных	60	Раздел по стандарту (указать)
Описание требований к производительности	60	Раздел по стандарту (указать)
Описание требований к надежности	30	Раздел по стандарту (указать)
Описание условий эксплуататции	30	Раздел по стандарту (указать)
Описание требований к ТС	30	Раздел по стандарту (указать)
Описание требований к совместимости	30	Раздел по стандарту (указать)
Примечания: Если по какой-либо позиции требуется большее, то программист имеет право обосновать его и (если я соглашусь) увеличить, но не более, чем до 2-х часов (по этой "строке"). Если такого увеличения (по мнению программиста) мало, он должен разделить такую строку на несколько строк с шагом не превышающим 2 часа. Ниже приводится пример детализации задания по написанию функции "Добавление типа" (kern_db_add_type) для ядра неважно какого проекта
Задача N	Нормативное время, мин	Что на выходе
Разработка функции "Добавление типа" ("kern_db_add_type")	400 (6,7 часа)	Задокументированная (стандарт SCH-5.1) php-функция.
Код проверки уже существующих типов	60	... комментированный
Код обработки свойств	30	... комментированный
Код генерации строки запроса	120	... комментированный
Код обработки сложных типов	100	... комментированный
Код создания ограничений для типа	30	... комментированный
Код создание генератора	30	... комментированный
Код создания триггера	30	... комментированный
....и.т.д....................................................

Всё было бы просто, если бы труд программиста можно было бы пронормировать подобно труду другого исполнителя, например, каменщика или токаря (выточил N болванок в соответствии с плановым заданием и без брака - вот и молодец). Но с программистом такой простой аналогии не получается... Конечно, можно пронормировать количество написанных операторов за период времени, но как оценить их качество, если конечного продукта ещё нет? 

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

Спасибо,

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

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

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

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

1. Техническое задание.

2. Эскизный проект.

3. Технический проект.

4. Рабочий проект.

5. Внедрение.

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

Теперь вернёмся к Вашим примерам. Вы приводите пример соответствующий этапу "Разработка технического задания" и в примере "Задача N" - этапу "Разработка программы". Я думаю, что это не вполне характерные примеры и вот почему:

- объём документа "Техническое задание" составляет около 20 листов, а "Эскизный проект" порядка 1000;

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

Таким образом, у меня возникают 2 вопроса:

1. Можно ли привести пример детализации работ по этапу "Разработка эскизного проекта" с шагом 2 часа?

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

С уважением,

Александр.

Уважаемый Александр!

Верно. Поэтому не стоит делать такие сравнения: вот есть работа программиста и он сложна и многофакторна. А вот есть работа (цит.) каменщика, токаря, ...... и т.д. - они простые и понятные. Будем уважать другие профессии - тем более, что задачи администрирования там тоже весьма нетривиальны.

Да. Можно.

Обычно ТЗ пишет, все-таки, разработчик.

Пожалуйста,

шаг 1. Возьмите Ваш конкретный проект;

шаг 2. Детализируйте задачу "предварительная разработка структуры входных и выходных данных" - т.е. разбейте ее на этапы;

.........................................................

а потом обсудим шаг 3.

Спасибо,

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

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

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

Шаг 1 и Шаг 2.

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

		период работы
Код работы	Название / описание	начало	конец
1.	Техническое задание	18.12.2006	30.10.2007
1.1.	Обоснование необходимости разработки программы	18.12.2006	07.02.2007
1.1.1.	Постановка задачи.	18.12.2006	15.01.2007
1.1.2.	Сбор исходных материалов.	16.01.2007	05.02.2007
1.1.3.	Выбор и обоснование критериев эффективности и качества разрабатываемой программы.	06.02.2007	07.02.2007
1.2.	Научно-исследовательские работы	08.02.2007	19.03.2007
1.2.1.	Определение структуры входных и выходных данных.	08.02.2007	16.02.2007
1.2.2.	Предварительный выбор методов решения задач.	19.02.2007	12.03.2007
1.2.3.	Обоснование целесообразности применения ранее разработанных программ.	13.03.2007	14.03.2007
1.2.4.	Определение требований к техническим средствам.	15.03.2007	16.03.2007
1.2.5.	Обоснование принципиальной возможности решения поставленной задачи.	19.03.2007	19.03.2007
1.3.	Разработка и утверждение технического задания	01.05.2007	30.10.2007
1.3.1.	Определение требований к программе.	01.05.2007	21.05.2007
1.3.2.	Разработка технико-экономического обоснования разработки программы.	22.05.2007	22.05.2007
1.3.3.	Определение стадий, этапов и сроков разработки программы и документации на нее.	23.05.2007	29.05.2007
1.3.4.	Выбор программных и технических средств реализации	03.09.2007	04.09.2007
1.3.5.	Определение необходимости проведения научно-исследовательских работ на последующих стадиях.	05.09.2007	05.09.2007
1.3.6.	Согласование и утверждение технического задания.	15.10.2007	30.10.2007
2.	Эскизный проект	31.10.2007	21.03.2008
2.1.	Разработка эскизного проекта	31.10.2007	26.02.2008
2.1.1.	Предварительная разработка структуры входных и выходных данных.	31.10.2007	13.11.2007
2.1.2.	Уточнение методов решения задачи.	14.11.2007	08.01.2008
2.1.3.	Разработка общего описания алгоритма решения задачи.	09.01.2008	25.02.2008
2.1.4.	Разработка технико-экономического обоснования.	26.02.2008	26.02.2008
2.2.	Утверждение эскизного проекта	27.02.2008	21.03.2008
2.2.1.	Разработка пояснительной записки.	27.02.2008	18.03.2008
2.2.2.	Согласование и утверждение эскизного проекта	19.03.2008	21.03.2008
3.	Технический проект	26.02.2008	17.06.2008
3.1.	Разработка технического проекта	26.02.2008	26.05.2008
3.1.1.	Уточнение структуры входных и выходных данных.	26.02.2008	03.03.2008
3.1.2.	Разработка алгоритма решения задачи.	04.03.2008	26.03.2008
3.1.3.	Определение формы представления входных и выходных данных.	27.03.2008	23.04.2008
3.1.4.	Определение семантики и синтаксиса языка.	24.04.2008	25.04.2008
3.1.5.	Разработка структуры программы.	28.04.2008	23.05.2008
3.1.6.	Окончательное определение конфигурации технических средств.	26.05.2008	26.05.2008
3.2.	Утверждение технического проекта	26.05.2008	17.06.2008
3.2.1.	Разработка плана мероприятий по разработке и внедрению программ.	27.05.2008	30.05.2008
3.2.2.	Разработка пояснительной записки.	26.05.2008	10.06.2008
3.2.3.	Согласование и утверждение технического проекта.	11.06.2008	17.06.2008
4.	Рабочий проект	26.05.2008	29.08.2008
4.1.	Разработка программы	26.05.2008	22.08.2008
4.1.1.	Программирование и отладка программы	26.05.2008	22.08.2008
4.2.	Разработка программной документации	18.06.2008	15.07.2008
4.2.1.	Разработка программных документов в соответствии с требованиями ГОСТ	18.06.2008	15.07.2008
4.3.	Испытания программы	16.07.2008	29.08.2008
4.3.1.	Разработка, согласование и утверждение программы и методики испытаний.	25.08.2008	29.08.2008
4.3.2.	Проведение предварительных приемо-сдаточных и других видов испытаний.	16.07.2008	12.08.2008
4.3.3.	Корректировка программы и программной документации по результатам испытаний.	13.08.2008	26.08.2008
5.	Внедрение	27.08.2008	04.09.2008
5.1.	Подготовка и передача программы	27.08.2008	04.09.2008
5.1.1.	Подготовка и передача программы и программной документации для сопровождения и (или) изготовления.	27.08.2008	29.08.2008
5.1.2.	Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление.	01.09.2008	02.09.2008
5.1.3.	Передача программы в фонд алгоритмов и программ.	03.09.2008	04.09.2008

Шаг 3 - ?

С уважением,

Александр.

Уважаемый Александр!

Таблицу Вашу вижу. Отвечу позже.

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

Эталонная производительность "по разработке заработных плат" в нашей компании = 4 должности в день. Чистого времени на предыдущие 3 сообщения Вам я затратил 20 минут.

Спасибо,

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

Вы пишете:  Чистого времени на предыдущие 3 сообщения Вам я затратил 20 минут.

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

Вы пишете: Эталонная производительность "по разработке заработных плат" в нашей компании = 4 должности в день.

Здесь Вы имеете в виду, что существуют нормативы производительности труда для всех ролей участников проекта?

С уважением,

Александр.

Уважаемый Александр!

Да, ничего он не подтверждает. Просто у меня сейчас стажировка и 32 Клиента одновременно. Соответственно, выкраиваю время.

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

Спасибо,

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

Вы неверно поняли смысл моего замечания относительно затрачиваемого нами времени. Меня впечатляет оперативность Вашей реакции с учётом Вашей занятости, и за это хочется сказать отдельное "СПАСИБО". При этом я полагаю, что если суммарно Вы затратили всего 20 минут на написание сообщений, то это суперрезультативно! Но дело не в этом... Суть моей мысли заключается в том, что для работы в команде требуются коммуникации между участниками проекта, а это требует времени. Следовательно, конечный результат зависит не только от производительности каждого из нас, взятого в отдельности.  И чем больше проект, чем больше членов в команде, тем больше времени будет затрачено на необходимые коммуникации. Это не требует доказательств, так как является объективной реальностью. Вот и всё.

Дабы не уйти в сторону от обсуждения основной темы я предпочёл бы вернуться к вопросу по обозначенному Вами шагу 3. Надеюсь, ответ на него многое прояснит.

С уважением,

Александр.

Уважаемый Александр!

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

ОК. Будем считать, что я и сам такой.

Поэтому я пока буду отвечать, как менеджер получивший Ваш проект на экспертизу. Ниже: беспокойства по плану, еще ниже: предложения.

Беспокойство 1. Имею стереотип о том, что этот план сильно "надут".

1.2.1.

Определение структуры входных и выходных данных.

08.02.2007

16.02.2007

• Делаю ................................
• Делаю ................................
• Делаю ................................
• .... и т.д. .............................
• Получаю первую версию "структуры входных и выходных данных"

Спасибо,

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

Описанные Вами "беспокойства" полностью соответствуют моим. Более того, в работе руководителя проекта проявляются признаки, свидетельствующие либо  о его недостаточной компетенции, либо о попытках манипулирования инвестором. Насколько я понимаю, любой план, составленный руководителем проекта - профессионалом, должен быть детализирован по шагам, соответствующим определённым работам, которые могут и должны быть завершены в течение нескольких часов, а результат этих работ должен быть видимым и поддаваться количественной и качественной оценке. Если так, то неспособность руководителя проекта составить подобный план будет свидетельствовать о его несоответствии занимаемой должности, а успешное составление детального плана позволит обеспечить жёсткий контроль над исполнением проекта и выстроить систему мотивации таким образом, чтобы исключить возможность манипулирования со стороны проектной команды.  Мои выводы верны?

Теперь о предложениях.

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

2. Мне тоже очень не нравится не детализированные шаги проекта, особенно в случае их длительности более месяца. На предложение сделать детализацию по всем этапам проекта с шагом, если не несколько часов, то хотя бы несколько дней, руководитель проекта отвечает приблизительно следующее: "Я могу сделать любую детализацию на этапах технического и рабочего проектов, но не могу запланировать ничего более определённого на этапе эскизного проекта, т. к. здесь мы заняты научными изысканиями, а наука - это предмет тёмный и детальному планированию не подлежит". Меня подобная аргументация не убеждает, но как доказать обратное? Вы рекомендуете дать поручение "разделить пункт на этапы" тем самым отвечая на вопрос "Что делать?". Но в тупик заводит вопрос "Как это сделать?". Именно поэтому я предлагал показать подобную детализацию шагов, соответствующим реальным задачам этапа "Разработка эскизного проекта" для реального проекта. По сути, для меня такой образец может стать решающим аргументом в пользу того, что подробная детализация плана возможна и необходима.

С уважением,

Александр.

Уважаемый Александр!

У каждого исследования существует какая-то цель. Например, цель Г.С. Альтшуллера, поставленная при создании ТРИЗ - это упростить процесс решения изобретательских задач. Точно так же целью Франсуа Виета было упростить решение уравнений первых четырех степеней. Поэтому должна быть определенная цель (или гамма целей) и у эскизного проекта. Например, в нашем случае такими целями было:

• Проверить и отладить механизм рисования карты.
• Протестировать скорость рисования карты на разных zoom'ах.
• Подобрать цветовые схемы для карты.
• Разработать и протестировать механизм масштабирования и перемещения по карте.
• Протестировать скорость масштабирования и перемещения.
• Протестировать и отладить роутинг.
• И т.д.

Подобные цели должен привести и Ваш менеджер проекта.

Вы рекомендуете дать поручение "разделить пункт на этапы" тем самым отвечая на вопрос "Что делать?". Но в тупик заводит вопрос "Как это сделать?".

Можно применить такой прием:

1. Начать составлять project plan для технического проекта с детализацией в 2 часа.
2. Если где-либо возникает "затык" (т.е. трудно раздробить задачу на подзадачи или оценить задачу по времени), то добавить цель для эскизного проекта. Например:
1. Исследовать методы решения задачи N и выбрать подходящий.
2. Оценить время, требуемое для решения задачи N.
3. И т.д.

С уважением,

Уважаемый Александр!

Такое может говорить человек, наукой не занимавшийся. Я бы с ним не спорил, а отправил с богом.

Подробнее отвечу чуть позже. К рекомендациям Кирилла Лебедева - присоединяюсь.

Спасибо,

Здравствуйте, Кирилл!

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

С уважением,

Александр.

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

Как я уже отметил в ответе Кириллу, мои вопросы относительно возможности детализации любых этапов любого проекта сняты. По всей видимости зрелость процесса разработки ПО у нас сейчас соответствует характеристике "стандарты приняты, но не соблюдаются". Думаю, что прежде всего следует навести порядок в этом отношении. Если Вас не затруднит, я просил бы оценить принятые у нас требования к составлению планов:

• работа/мероприятие имеет длительность свыше 0,2-1% от предполагаемого срока проекта;
• при выполнении работы/мероприятия будут произведены финансовые затраты или произойдут иные финансовые потоки;
• работа/мероприятие имеет краткую длительность (событие) и нулевые финансовые потоки, но событие имеет критическую важность для продолжения проекта".

А также:

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

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

С уважением,

Александр.

Уважаемый Александр!

Пожалуйста! Рад, если мои рекомендации оказались полезны.

С уважением,

Уважаемый Александр!

ОК.

Хотя диапазон задан Вами достаточно жестко (только на очень длинных проектах могут пойти "разбросы"), я бы рекомендовал указывать не относительные значения (т.е., % в Вашем случае), а абсолютные - т.е., буквально нормо-часы. Иначе Вы будете отводить разное время на одни и те же работы (в зависимости от того, в рамках какого проекта (длинного или короткого) они выполняются). А - собственно говоря - почему? Работа, которая должна быть выполнена за 2 часа должна быть выполнена за 2 часа независимо от того, сколько длится весь проект.

Поэтому просто установите предел (шаг) описания: например, 2 часа. Постепенно, это приведет к тому, что у Вас начнет накапливаться "Справочник работ" (и соответствующие нормы времени).

По крайней пере, на первых этапах (НИР, эскизное проектирование...) установите шаг в 2 часа. Я повторяю это не из догматизма и даже не из желания ускорить эти этапы, а, как раз, потому, что такой принцип вынуждает (в самом хорошем/продуктивном смысле этого слова) действительно думать над проектом, выделять ключевые задачи, находить заранее и описывать "смутные места" проекта. Потому, что когда разработчик говорит: "Я не могу данную задачу разделить на короткие подзадачи - это значит, что вот это самое "смутное место" он должен вынести и описать/объявить/разобрать отдельно". (Это показал в своем примере Кирилл Лебедев).

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

Спасибо за оказанную помощь.

ОК. Спасибо и Вам,

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

Ваши рекомендации понятны, но в связи с ними у меня возникли 2 вопроса:

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

2. Вы пишете:

Постепенно, это приведет к тому, что у Вас начнет накапливаться "Справочник работ" (и соответствующие нормы времени).

Подобный справочник уникален для каждого разработчика, либо существуют соответсвующие нормативные документы подобно ГЭСН в строительстве? Если существуют, прошу дать ссылку. Если не существуют и речь идёт о том, что каждый разработчик должен накапливать собственную статистику и сам устанавливать для себя нормативы, то могу ли я рассчитывать на Вашу помощь?

С уважением,

Александр.

Уважаемый Александр!

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

Спасибо за детальные разъяснения.

Из Вашего ответа на 1-й вопрос я делаю вывод о том, что далеко не для всех этапов и шагов проекта существует прямая зависимость между масштабом проекта и длительностью этапа. В связи с этим, корректную экспертную оценку плана с учётом технологии и особенностей соответствующих процессов, может сделать только профессионал с глубокими знаниями в предметной области данного проекта и опытом работы в проектных командах. Поэтому следует задаваться абсолютными значениями человеко-часов, рассчитанными не относительно некого предположительного срока проекта, но на основании нормативов по соответствующим видам работ. Я верно формулирую? Я полностью согласен с тем, что необходимо проводить максимально возможную детализацию рабочих планов как с целью повышения точности планирования, так и для недопущения искусственного "раздувания" планов. Что касается процедуры планирования, то я не вижу существенного противоречия в том, что первоначальный план может быть сделан как "снизу-вверх", так и "сверху-вниз". Просто, если после планирования "сверху-вниз" длительность шага превысит, например, 1% от срока всего проекта, то следует задуматься о дальнейшей детализации, либо о сокращении длительности самого шага.   

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

С уважением,

Александр.

Уважаемый Александр!

Это верно. Например, написание слова "например" не займет больше времени, если вот это предложение, которое я пишу будет длинным-предлинным. Я могу потратить больше времени, размышляя о том не написать ли, например, вместо "например", слово "допустим" и также над тем, коряво или нет будет звучать предложение в этом случае и т.д. Но эти затраты времени никак не связаны с длиной предложения.

Ну, вот это один из приемов (разделение работы на короткие интервалы (например, 2 часа)), который упрощает требования к квалификации менеджера (но не в целом относительно предметной области, а только для частной задачи = понимания продолжительности и уровня (сложности) работы ).

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

Я просто не знаю. Предполагаю, что их нет, но, конечно, могу ошибаться.

Да, он в разработке, но появится, конечно.

Спасибо,

Уважаемый Александр!

"Понимаю, что сейчас разрабатываемый алгоритм находится в "сыром" выде, но если информация о нём не является закрытой, то впоследствии для меня было бы очень интересно понять, каким образом будет упрощён вопрос о нормировании?"

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

Наиболее частой ошибкой, которую совершают программисты при работе над проектом, является смешение этапов постановки задачи, проектирования и написания кода в один этап. К сожалению, в компаниях, где я работал, было принято работать именно так. Многие программисты думают "в коде" и поэтому обнаруживают проблемы не на этапах постановки задачи и проектирования, а при написании кода. Как результат, это приводит к многочисленным ошибкам и "заплаткам" в коде, и  через какое-то время (весьма непродолжительное!) этот код становится невозможно сопровождать. Разрабатываемый алгоритм четко разделяет эти этапы. Каждый этап разбивается на шаги, а шаги содержат не только описания цели (того, что нужно сделать), но и описания приемов (т.е. как это сделать).

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

С уважением,

Уважаемые Коллеги!

Если он не сачкует, не занимается ленью второго уровня, не делает боковиков...

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

Спасибо,

Здравствуйте, Кирилл!

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

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

С уважением,

Александр. 

Уважаемый Александр!

А раз результаты труда будут измеряемы, то можно будет создать такую модель заработной платы, которая будет стимулировать производительность и соблюдение технологии.

Желаю Вам и вашей команде этого, а также и других успехов!

Благодарю за теплые пожелания! :)

С уважением,

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

С уважением,

Александр.

Здравствуйте, Кирилл!

Сергей, добрый день!

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

С уважением,
Александр.

• Есть Заказчик.
• Есть конструктор (архитектор) = делает и эскизный проект, и основной, и осуществляет авторский надзор, но НЕ разрабатывает реализацию. (И это принципиально).
• Есть технолог = который получает проект и разрабатывает технологию (способ реализации  проекта), но НЕ делает проекта (хотя может иметь к нему претензии). (И это принципиально).
• Есть «собственно, производство» = где реализуют технологию, но НЕ имеют права ее изменять. (И это тоже принципиально).

• высший уровень - "выдающиеся математики" (например, среди них были Адриен Лежандр и Лазарь Карно). "Выдающиеся" готовили математическое обеспечение.
• второй уровень -  "образованные "технологи". Они организовывали рутинный процесс вычислительных работ.
• низший уровень - "вычислители = computers". От них требовалась только аккуратность в сложении и вычитании. В основном, на эту работу нанимали девушек (экономя на з.п.)

Уважаемые коллеги, добрый день!

Спасибо за ваши ответы. Из них я понял следующее:

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

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

С уважением,
Александр.

Уважаемые Кирилл и Сергей!

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

С уважением,
Александр.

• анализирует требования к информационной системе;
• уточняет их, модифицирует, добавляет новые требования;
• описывает поведение ИС в виде ряда моделей (вариантов использования, IDEF0, IDEF3, UML и т.д.).

• Предварительная разработка структуры входных и выходных данных
• Уточнение методов решения задачи
• Разработка общего описания алгоритма решения задачи
• Разработка технико-экономического обоснования

Здравствуйте, Кирилл!

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

С уважением,
Александр.

Уважаемый Сергей Валерьевич!

Уважаемые Коллеги!

По результатам полученного за 5 последних лет опыта хотел бы кое-что добавить и кое-где изменить свою точку зрения.