На сайте ведутся работы 2-я нить обсуждения "Помогите составить систему мотивации для программиста!" | Нематериальное стимулирование, компенсационные пакеты | Бизнес-форум TRIZ-RI
9737
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ
Все категории » Нематериальное стимулирование, компенсационные пакеты » Что мешает программистам IT-отделов…

2-я нить обсуждения "Помогите составить систему мотивации для программиста!"

Ваши данные (просмотреть)
в избранные темы
Политика конфиденциальности

Обсуждения-аналоги

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

Авторы

Скрыть / Показать
2007-11-08 16:19:02
Александр » Сергей В. Сычев

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

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

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

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

[Показать все ответы на это сообщение]
2007-11-09 09:56:31
Сергей В. Сычев » Александр

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

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

 

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

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

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

 

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

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

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

 

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


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

Спасибо,

[Показать все ответы на это сообщение]
2007-11-09 16:47:03
Александр » Сергей В. Сычев

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

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

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

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

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

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

С уважением,

Александр.

[Показать все ответы на это сообщение]
2007-11-11 15:30:02
Сергей В. Сычев » Александр
Уважаемый Александр!
 
Мой вопрос заключается в следующем: каким образом можно корректно измерить результативность каждого участника проектной команды? Или, другими словами, что можно и нужно использовать в качестве эталонов применительно к процессам создания ПО?

 
1. Основной критерий: "Результативность по времени реализации проекта".
 
Поручите рукодителю проекта описать все этапы проекта (последовательность работ "от начала и до конца") с заданным шагом, например, в 2 часа. Крайне редко (даже на действительно сложных проектах) бывает так, что каждый из таких шагов трудно выделить. Это первый шаг к определению "эталонного времени" реализации проекта, а также к правильному распределению функций среди участников проекта.
 
2. Кроме того, полезно завести определенные стандарты на проектирование и кодирование. И - соответственно - (относительно стандартов) добавить критерий: "Результативность по качеству".
 
Не знаю, верно ли я понял Вас на этот раз.
 
Спасибо,
[Показать все ответы на это сообщение]
2007-11-12 12:11:48
Александр » Сергей В. Сычев

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

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

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

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

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

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

 

С уважением,

Александр.

[Показать все ответы на это сообщение]
2007-11-12 16:35:15
Сергей В. Сычев » Александр

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

Добавлю деталировки к примеру Кирилла (как это делается у нас в компании). Обратите внимание на деталировку по русски в примере 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 болванок в соответствии с плановым заданием и без брака - вот и молодец). Но с программистом такой простой аналогии не получается... Конечно, можно пронормировать количество написанных операторов за период времени, но как оценить их качество, если конечного продукта ещё нет? 

 

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

 

Спасибо,

 

[Показать все ответы на это сообщение]
2007-11-12 17:47:39
Александр » Сергей В. Сычев

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

С уважением,

Александр.

[Показать все ответы на это сообщение]
2007-11-12 18:04:42
Сергей В. Сычев » Александр

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

 

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

 

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

 

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

 

Да. Можно.

 

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

 

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

 

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

 

Пожалуйста,

 

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

 

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

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

 

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

 

Спасибо,

 

[Показать все ответы на это сообщение]
2007-11-13 09:54:31
Александр » Сергей В. Сычев

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

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

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

Шаг 1 и Шаг 2.

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

период работы
Код работы Название / описаниеначалоконец
    
1.Техническое задание18.12.200630.10.2007
1.1.Обоснование необходимости разработки программы18.12.200607.02.2007
1.1.1.Постановка задачи.18.12.200615.01.2007
1.1.2.Сбор исходных материалов.16.01.200705.02.2007
1.1.3.Выбор и обоснование критериев эффективности и качества разрабатываемой программы.06.02.200707.02.2007
1.2.Научно-исследовательские работы08.02.200719.03.2007
1.2.1.Определение структуры входных и выходных данных.08.02.200716.02.2007
1.2.2.Предварительный выбор методов решения задач.19.02.200712.03.2007
1.2.3.Обоснование целесообразности применения ранее разработанных программ.13.03.200714.03.2007
1.2.4.Определение требований к техническим средствам.15.03.200716.03.2007
1.2.5.Обоснование принципиальной возможности решения поставленной задачи.19.03.200719.03.2007
1.3.Разработка и утверждение технического задания01.05.200730.10.2007
1.3.1.Определение требований к программе.01.05.200721.05.2007
1.3.2.Разработка технико-экономического обоснования разработки программы.22.05.200722.05.2007
1.3.3.Определение стадий, этапов и сроков разработки программы и документации на нее.23.05.200729.05.2007
1.3.4.Выбор программных и технических средств реализации03.09.200704.09.2007
1.3.5.Определение необходимости проведения научно-исследовательских работ на последующих стадиях.05.09.200705.09.2007
1.3.6.Согласование и утверждение технического задания.15.10.200730.10.2007
2.Эскизный проект31.10.200721.03.2008
2.1.Разработка эскизного проекта31.10.200726.02.2008
2.1.1.Предварительная разработка структуры входных и выходных данных.31.10.200713.11.2007
2.1.2.Уточнение методов решения задачи.14.11.200708.01.2008
2.1.3.Разработка общего описания алгоритма решения задачи.09.01.200825.02.2008
2.1.4.Разработка технико-экономического обоснования.26.02.200826.02.2008
2.2.Утверждение эскизного проекта27.02.200821.03.2008
2.2.1.Разработка пояснительной записки.27.02.200818.03.2008
2.2.2.Согласование и утверждение эскизного проекта19.03.200821.03.2008
3.Технический проект26.02.200817.06.2008
3.1.Разработка технического проекта26.02.200826.05.2008
3.1.1.Уточнение структуры входных и выходных данных.26.02.200803.03.2008
3.1.2.Разработка алгоритма решения задачи.04.03.200826.03.2008
3.1.3.Определение формы представления входных и выходных данных.27.03.200823.04.2008
3.1.4.Определение семантики и синтаксиса языка.24.04.200825.04.2008
3.1.5.Разработка структуры программы.28.04.200823.05.2008
3.1.6.Окончательное определение конфигурации технических средств.26.05.200826.05.2008
3.2.Утверждение технического проекта26.05.200817.06.2008
3.2.1.Разработка плана мероприятий по разработке и внедрению программ.27.05.200830.05.2008
3.2.2.Разработка пояснительной записки.26.05.200810.06.2008
3.2.3.Согласование и утверждение технического проекта.11.06.200817.06.2008
4.Рабочий проект26.05.200829.08.2008
4.1.Разработка программы26.05.200822.08.2008
4.1.1.Программирование и отладка программы26.05.200822.08.2008
4.2.Разработка программной документации18.06.200815.07.2008
4.2.1.Разработка программных документов в соответствии с требованиями ГОСТ18.06.200815.07.2008
4.3.Испытания программы16.07.200829.08.2008
4.3.1.Разработка, согласование и утверждение программы и методики испытаний.25.08.200829.08.2008
4.3.2.Проведение предварительных приемо-сдаточных и других видов испытаний.16.07.200812.08.2008
4.3.3.Корректировка программы и программной документации по результатам испытаний.13.08.200826.08.2008
5.Внедрение27.08.200804.09.2008
5.1.Подготовка и передача программы27.08.200804.09.2008
5.1.1.Подготовка и передача программы и программной документации для сопровождения и (или) изготовления.27.08.200829.08.2008
5.1.2.Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление.01.09.200802.09.2008
5.1.3.Передача программы в фонд алгоритмов и программ.03.09.200804.09.2008

Шаг 3 - ?

С уважением,

Александр.

[Показать все ответы на это сообщение]
2007-11-13 11:34:32
Сергей В. Сычев » Александр

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

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

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

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

Спасибо,

[Показать все ответы на это сообщение]
2007-11-13 13:44:16
Александр » Сергей В. Сычев

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

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

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

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

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

 

С уважением,

Александр.

[Показать все ответы на это сообщение]
2007-11-13 14:09:06
Сергей В. Сычев » Александр

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

 

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

 

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

 

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

 

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

 

Спасибо,

[Показать все ответы на это сообщение]
2007-11-13 16:27:42
Александр » Сергей В. Сычев

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

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

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

 

С уважением,

Александр.

[Нет ответов на это сообщение]
2007-11-13 16:44:53
Сергей В. Сычев » Александр

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

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

 

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

 

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

 

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

 

Вот почему я так думаю. Конечно, написано "верно" (НИР, ТЗ, "эскизный проект", "технический проект", "рабочий проект" и т.д.), но
 
1.1. Беспокоит дублирование работ на уровне пред. программных проектов. Я пониманию, что одни и те же формулировки в контексте разных этапов ("эскизный проект", "технический проект", "рабочий проект") означают разный качественный уровень проработки. Но почему тогда самые первые этапы плана (например, "НИР") не детализированы, а описаны в общей форме?
 
1.2. Беспокоит, что в плане нет никакой специфики проекта и потому указанное время, скорее всего, взято с потолка. Например, такой план "в принципе можно написать" хоть "для игры", хоть "для интернет - магазина", хоть для "роутинга" и т.д. Понимаю, что принципы планирования общие, но, все же, этот план, на мой взгляд, "лозунговый" - т.к., в конкретном плане работ были бы указания на стандарты или фразы содержащие специфику (например, "разработка мультикорзины" и т.п.).
 
1.3. Беспокоит отсутствие деталировки "рабочего проекта". Он состоит из 1 строки "программирование и отладка программы", которые занимают 3 месяца (одной строкой) после 5-ти месячного периода всех этих "НИР и пред. программных проектов".  (Хотя, может быть, после эскизного проекта соотв. деталировка появится, но - опять же - почему тогда, например, один из первых этапов - "НИР" - такой лозунговый?).
 
Беспокойство 2.  Боюсь, что этот план сделан "для Заказчика", а фактически программу будут писать совсем по другим планам.
 
Далее предложения.
 
Предложение 1. Имеет смысл прежде всего сформулировать ключевые функции разрабатываемой Вами программы. И затем перейти к предложению 2.
 
Предложение 2.  Поскольку большое пьянство начинается с маленьких рюмок, давайте для начала детализируем одну строку (раздела "НИР") Вашего плана.
 

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

08.02.2007

16.02.2007

 
Пояснение: Мне не нравится не детализированная неделя работы. И если у Вас есть аргумент о том, что последующие позиции пока (до разработки) естественно размыты (прошу прощения, если у Вас такого аргумента нет - просто он вероятен), то "первые позиции" плана детализировать стоит. Поэтому поручите этот пункт разделить на этапы. Буквально вот так:
  • Делаю ................................
  • Делаю ................................
  • Делаю ................................
  • .... и т.д. .............................
  • Получаю первую версию "структуры входных и выходных данных"

Спасибо,

 

[Показать все ответы на это сообщение]
2007-11-14 10:41:22
Александр » Сергей В. Сычев

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

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

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

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

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

 

С уважением,

Александр.

[Показать все ответы на это сообщение]
2007-11-14 12:41:16
Кирилл Лебедев » Александр

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

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

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

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

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

 

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

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

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

С уважением,

[Показать все ответы на это сообщение]
2007-11-14 13:02:13
Сергей В. Сычев » Александр

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

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

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

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

Спасибо,

[Показать все ответы на это сообщение]
2007-11-14 16:18:02
Александр » Кирилл Лебедев

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

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

С уважением,

Александр.

[Показать все ответы на это сообщение]
2007-11-14 16:52:33
Александр » Сергей В. Сычев

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

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

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

А также:

"Полное количество элементов иерархического списка, как правило, не должно быть более 100-300. Только в очень крупных проектах можно использовать список с большим количеством элементов. В первой версии Плана проекта иерархический список может состоять из 20-40 элементов. В последующих версиях количество элементов может увеличиваться".

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

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

 

С уважением,

Александр.

[Показать все ответы на это сообщение]
2007-11-14 19:06:15
Кирилл Лебедев » Александр

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

Большое спасибо за участие, Вы оказали действенную помощь.

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

С уважением,

[Нет ответов на это сообщение]
2007-11-15 10:10:14
Сергей В. Сычев » Александр

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

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

 

ОК.

 

"В качестве элементов декомпозиции используются работы или мероприятия, характеризующиеся хотя бы одним из следующих признаков:

  • работа/мероприятие имеет длительность свыше 0,2-1% от предполагаемого срока проекта;

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

 

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

 

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

 

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

 

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

 

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

 

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

[Показать все ответы на это сообщение]
2007-11-15 11:22:02
Александр » Сергей В. Сычев

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

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

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

2. Вы пишете:

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

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

 

С уважением,

Александр.

[Показать все ответы на это сообщение]
2007-11-15 18:00:03
Сергей В. Сычев » Александр

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

 

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

 

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

Причина 2. Способ (технология) выполнения работ.

Известно, что в рамках технологической цепочки при увеличении общего объема (заказа) трудоемкость возрастет  не на всех операциях. Самый известный пример - это полиграфия: чем длиннее заказ (больше тираж), тем ниже себестоимость каждого экземпляра. И это понятно: предпечатная подготовка делается 1 раз, какой бы тираж одного заказа мы бы не печатали. Подобное свойственно не только печатному процессу, но и многим другим.
 
Более того, если трудоемкость возрастает "пропорционально объему" - это говорит о неправильном распределении работ или вообще об отсутствии технологии и о присутствии на фирме не бизнес-процесса, а "натурального хозяйства", где каждый, как дачник окучивает свои 6 соток "от и до". Тогда, конечно, чем больше "дач", тем пропорционально больше работы. Но даже из 1000 дач нельзя создать одной приличной фермы.
 
Так и у программистов: когда они распределяют работу между собой "по объектам" ("по законченным подпроектам" и т.п.), а не по функциям, общая трудоемкость большого проекта, по мере его развития, возрастает даже не пропорционально, а лавинообразно (хотя работа каждого из них необязательно будет сложной).

Причина 3. Производительность не равна работе.
 
Производительность - это когда мы достигаем бОльших результатов меньшим количеством работы. Именно за производительность и надо платить премии.

 

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

 

Насколько мне известно, такого общего справочника пока не существует. Но скоро должны появиться более надсистемные "общие вещи": например, общий пошаговый "алгоритм эффективной разработки программных систем". Наличие такого алгоритма настолько упростит вопрос о нормировании, что может быть он (не являясь справочником работ) сможет выполнить его функцию. (Кирилл Лебедев, при необходимости, здесь меня поправит).
 
Спасибо,
[Показать все ответы на это сообщение]
2007-11-16 10:45:20
Александр » Сергей В. Сычев

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

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

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

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

 

С уважением,

Александр.

[Показать все ответы на это сообщение]
2007-11-16 19:19:29
Сергей В. Сычев » Александр

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Спасибо,

[Нет ответов на это сообщение]
2007-11-16 22:24:16
Кирилл Лебедев » Александр

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

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

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

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

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

С уважением,

[Показать все ответы на это сообщение]
2007-11-17 12:12:58
Сергей В. Сычев » Всем

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

Дело в том, что основное время при разработке софта тратится не на программирование как таковое (т.е. написание кода), а на продумывание.

 

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

 

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

 

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

 

Спасибо,

[Нет ответов на это сообщение]
2007-11-19 12:05:22
Александр » Кирилл Лебедев

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

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

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

 

С уважением,

Александр. 

[Показать все ответы на это сообщение]
2007-11-19 14:56:50
Кирилл Лебедев » Александр

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

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

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

 

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

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

С уважением,

[Показать все ответы на это сообщение]
2007-11-19 16:21:06
Александр » Кирилл Лебедев

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

 

С уважением,

Александр.

[Нет ответов на это сообщение]
2007-12-19 12:15:55
Александр » Всем

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

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

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

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

[Показать все ответы на это сообщение]
2007-12-20 14:25:27
Сергей В. Сычев » Александр
Уважаемый Александр!

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

Выражение "не способны" может быть не очень удачно.

Или, другими словами, является ли нормальной организационная схема проекта, в которой функциональные обязанности одних специалистов ограничены техническим заданием и эскизным проектом, а других - техническим проектом?

Человечество (и бизнес) развивается через разделение труда.


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

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

Мне кажется реализация больших программных продуктов постепенно тоже доживет до этой схемы «Архитектор – Технолог – Кодер». Сейчас в понимании этого процесса (по моему мнению) существует проскок уровня «технолог». Основные публикации сводятся к дихотомии «Архитектор – Кодер» и все споры идут о «плюсах и минусах» разделения этих сущностей или соединения их «в одном лице». Но верная модель такая: «Архитектор – Технолог – Кодер».

 Да и в компьютерах с этого все и начиналось (если поглядеть по ссылке).

Цитата:

"С 1790 по 1800 барон Гаспар де Прони (руководивший бюро переписи во Франции) для уточнения логарифмических и тригонометрических таблиц создавал (и весьма успешно) еще не "вычислительную машину", а "вычислительную мануфактуру". А более конкретно: 

Гаспар де Прони перенес идею разделения труда на вычислительный процесс. Де Прони распределил исполнителей по трем разным качественным уровням:

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

-------------------

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

Спасибо,
[Нет ответов на это сообщение]
2007-12-20 15:26:18
Кирилл Лебедев » Александр
Уважаемый Александр!

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

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

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

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

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

С уважением,
[Нет ответов на это сообщение]
2007-12-20 16:38:09
Александр » Всем

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

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

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

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

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

[Показать все ответы на это сообщение]
2007-12-20 17:56:53
Кирилл Лебедев » Александр
Уважаемый Александр!

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

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

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

Важно только у руководителя уточнить: "Для выполнения каких задач требуется системный аналитик?"  Что он должен и может сделать, чего не могут сделать остальные члены команды?

На мой взгляд, руководитель проекта должен конкретизировать причины задержки. Например:

Системный аналитик должен был сделать то-то и то-то. Но его нет. И поэтому мы это делали сами. Поскольку у нас нет опыта, то мы допустили такие-то и такие-то ошибки. На их исправление ушло столько-то времени.

И в конце сделать вывод: Чтобы подобных ошибок больше не допускать, мы решили сделать то-то и то-то.

С уважением,
[Нет ответов на это сообщение]
2007-12-20 18:16:33
Сергей В. Сычев » Александр
Уважаемый Александр!

Присоединяюсь к ответу Кирилла Лебедева.

Истина конкретна.

Успеха,
[Нет ответов на это сообщение]
2007-12-21 13:10:54
Александр » Всем

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

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

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

[Показать все ответы на это сообщение]
2007-12-21 15:03:36
Кирилл Лебедев » Александр
Уважаемый Александр!

Буду вам весьма признателен, если сможете ответить ещё на один мой вопрос - для выполнения каких специфических задач обычно требуется системный аналитик на стадии технического проекта
Насколько я понимаю, системный аналитик:
  • анализирует требования к информационной системе;
  • уточняет их, модифицирует, добавляет новые требования;
  • описывает поведение ИС в виде ряда моделей (вариантов использования, IDEF0, IDEF3, UML и т.д.).
В общем, если говорить кратко, переводит бизнес-требования в технические.

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

С уважением,

[Показать все ответы на это сообщение]
2007-12-24 13:45:32
Александр » Кирилл Лебедев
Здравствуйте, Кирилл!

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

С уважением,
Александр. 
[Показать все ответы на это сообщение]
2007-12-24 17:18:27
Кирилл Лебедев » Александр
Уважаемый Александр!

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

Да, это так.

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

Согласно ГОСТ 19.102-77 "Стадии разработки" этап "Разработка эскизного проекта" подразумевает выполнение таких работ:
  • Предварительная разработка структуры входных и выходных данных
  • Уточнение методов решения задачи
  • Разработка общего описания алгоритма решения задачи
  • Разработка технико-экономического обоснования
Для того, чтобы эти этапы можно было выполнить, перед началом эскизного проекта должны быть сформулированы не только предварительные бизнес-требования, но и предварительные технические требования. Это означает, что определенная работа по преобразованию бизнес-требований к техническим требованиям тоже должна быть выполнена.

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

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

Могут быть исключения, связанные с какой-нибудь узкой профессиональной областью, например, с эргономикой и UI (пользовательским интерфейсом). Эскизный проект может обладать плохим интерфейсом. А для технического проекта нанимается специальный человек (или команда), которые профессионально занимаются эргономикой и UI. В свою очередь, для тестирования разработанного UI они тоже могут создать свой эскизный проект.

С уважением,
[Показать все ответы на это сообщение]
2007-12-25 10:16:19
Александр » Кирилл Лебедев

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

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

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

[Нет ответов на это сообщение]
2013-06-25 01:07:35
Кирилл Лебедев » Сергей В. Сычев

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

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


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

1. Основной критерий: "Результативность по времени реализации проекта".

Я всё же склоняюсь к тому, что основных критерия три:

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

Причин для этого несколько:

  1. Чтобы дать точную оценку, нужно знать то, как будет устроена и как будет функционировать программа (с точки зрения реализации). Т.е. нужно заранее обладать знанием о техническом дизайне программы (вплоть до мельчайших подробностей!). Но это невозможно, т.к. технический дизайн является результатом работы над проектом, а не входными данными. Более того, большая часть времени работы над проектом тратится инженером не на программирование, а на разработку технических решений. Это - один из основных результатов работы инженера.
  2. При одновременной работе большого количества людей над одним проектом существенным образом увеличиваются затраты на коммуникации. Часто переаллокация ресурсов на задачу не ускоряет, а, наоборот, замедляет время выполнения задачи. Попытки упростить зависимости между задачами и людьми, их выполняющими, при помощи классических инструментов (Microsoft Project и диаграмм Гантта) обречены на провал. Через некоторое время диаграммы Гантта разъезжаются, и стройный план проекта становится неадекватным. При таком подходе основное время менеджера тратится на перестроение диаграмм и перепланирование. Более адекватный способ - это управление зависимостями. Он заключается в том, что каждый инженер ответственен за выявление зависимостей (т.е. тех людей и задач, от которых зависит выполнение его задачи) и за отслеживание, чтобы зависимости разрешались заблаговременно до окончания срока сдачи задачи. Т.е. инженер должен сигнализировать о зависимостях как людям, от которых он зависит, так и своему менеджеру.
  3. Изначальный дизайн программы (я имею в виду дизайн с точки зрения пользователя) не является чем-то, высеченным из камня. Если продюсер видит, что использовать программу при первоначальном дизайне неудобно, то он может изменить дизайн. И это будет правильно, потому что продукт разрабатывается для пользователя, и он должен быть удобным в использовании. Кроме того, продюсер с подачи инженера может предложить иной дизайн, если первоначальный дизайн требует каких-то сверхусилий или слишком дорог.
Поэтому при работе над средними и большими проектами (пере-)оценка проекта выполняется на разных этапах.

В самом начале определяется идея проекта (т.н. креативное ядро) и определяется класс проекта (его длительность и размер команды). Первая оценка выполняется весьма грубо на основе исторических данных.

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

Наконец, концепция перерастает в детальный дизайн-документ, на основе которого инженер расписывает технический дизайн, делает work breakdown structure (т.е. составляет перечень конкретных технических задач) и производит их оценку.

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


Яндекс.Метрика