Что делать, если служба такси не развивается?
Пакет документов, организующих управление службой такси, включая управление приемом, выполнением и диспетчированием заказов, а также...
На сайте ведутся работы
сегодня 10930 Подписчиков
Здравствуйте, Сергей Валерьевич!
По одной из ссылок я вышел на это обсуждение и был весьма заинтересован развёрнутой дискуссией. Судя по датам, много "воды утекло" с тех пор, но заданные вопросы остаются и, скорее всего, ещё долго будут оставаться актуальными. В своём последнем сообщении Максиму Болотному Вы пишете: "...Это обсуждение на Форуме пусть пока "отдохнет". Ибо, неизбежно будет общение по E-mail и личные встречи (учитывая, что мы живем в одном городе). Однако, то, что получится - выложим на сайт. И в надлежащий момент дадим здесь ссылку".
Поскольку ссылок до сих пор не обнаруживается, хотелось бы узнать, к чему Вы с Максимом в конце концов пришли? Спрашиваю об этом, в первую очередь, потому, что, на мой взгляд, в процессе дискуссии вы ушли от обсуждения основной проблемы - методов нормирования и оценки результативности труда участников проектных команд в IT-отделах, к непродуктивному обмену мнениями по вопросу принципиальной возможности и целесообразности применения подобной методики в процессе создания ПО. Я сейчас занят решением аналогичной задачи и заинтересован в открытом обсуждении практических аспектов.
С уважением, Александр.
Здравствуйте, Александр!
Я сейчас занят решением аналогичной задачи и заинтересован в открытом обсуждении практических аспектов.
1. Я думаю более приближена к Вашей ситуации вот эта тема.
2. Касательно данного обсуждения. Я не считаю обмен мнениями по вопросу принципиальной возможности и целесообразности применения подобной методики в процессе создания ПО непродуктивным.
Если Вы действительно заняты решением аналогичной задачи, то с большой степенью вероятности Вам предстоит преодолевать хорошо подкрепленные "отмазки" о "принципиальной невозможности" и т.п., и проч. Собственно, если Вы внимательно поглядите в аналогичных обсуждениях (слева) ответы/протесты программистов, то Вы это почувствуете.
Более того, именно для иллюстрации такой возможности (в том числе, для решения творческих задач) пришлось поставлять "примеры в студию", как того потребовал Максим.
И хоть потом Максим так и не прислал мне примеров, примеры в студию доставлены были и продолжают доставляться.
Смотрите публикации С.В. Сычева и К.А. Лебедева:
3. Касательно практических аспектов. Задайте Ваш конкретный вопрос. Буду рад ответить.
Спасибо,
Здравствуйте, Сергей!
Спасибо за быстрый ответ и готовность к обсуждению обозначенных мною проблем. В первую очередь очень кратко хотелось бы прокомментировать Ваши замечания по пунктам.
1. Рекомендованную Вами тему я просмотрел ещё вчера. На мой взгляд там дискуссия также ушла в сторону от зарплатной задачи к обсуждению технических нюансов, связанных непосредственно с программированием. Меня же интересует, в первую очередь, менеджмент проекта и мотивация участников проектных команд.
2. Бесспорно, сама по себе дискуссия о целесообразности формализации процесса разработки ПО очень важна, если у одной из сторон есть сомнения по этому поводу. Я же имел в виду то, что если в данном обсуждениии заявлена тема "Помогите составить систему мотивации для программиста!", то в процессе дискуссии с Максимом приблизиться к решению не удалось. Я полностью согласен с Вашей аргументацией в этом обсуждении и полагаю, что если оно закончилось именно таким образом, то "шарик" на стороне Вашего оппонента. Спасибо за указание на аналогичные обсуждения, действительно, я уже сравнительно давно заметил, что проблемы и "отмазки" типичны, как для указанных Вами обсуждений, так и для моего практического опыта.
3. С рекомендованными Вами статьями я ознакомился, но и они, на мой взгляд, также связаны с методами решения задач программирования, но не с управлением проектами. В этом смысле мне в своё время очень понравилась рекомендованная на вашем сайте статья "Правильные бизнес-процессы для гениев программирования". Мой вопрос заключается в следующем: каким образом можно корректно измерить результативность каждого участника проектной команды? Или, другими словами, что можно и нужно использовать в качестве эталонов применительно к процессам создания ПО?
Если необходимо дать какие-либо дополнительные разъяснения, я готов это сделать по вашему запросу.
С уважением,
Александр.
Здравствуйте, Сергей!
Вы поняли меня абсолютно верно. Ваши рекомендации по критериям оценки результативности мне понятны. Однако, пока не всё ясно с их практическим применением. Для начала мне хотелось бы привести цитату из книги "Мифический человеко-месяц" Брукса:
"Во многих отношениях управление большим проектом разработки программного обеспечения аналогично любому другому крупному начинанию — в большей мере, чем обычно считают программисты. Однако во многих отношениях имеет отличия — в большей мере, чем обычно предполагают профессиональные менеджеры".
На мой взгляд - это очень верная оценка. Отличия обусловлены спецификой процесса создания ПО и для верного понимания проблемы необходимо выяснить, в чём же состоят его отличия от другого производственного процесса. На первый взгляд, с точки зрения менеджера, никаких существенных отличий нет. В обоих случаях результатом является готовый продукт, удовлетворяющий требованиям заказчика, в процессе работы должны появляться промежуточные результаты, соответствующие завершению очередных этапов. В обоих случаях в обязательном порядке должен быть составлен детальный календарный план и, по крайней мере, промежуточные результаты должны ему соответствовать. Если бы этапы или шаги проекта "вписывались" в пределы календарного месяца (период начисления и выплаты заработной платы участникам проекта), то задача была бы тривиальной, но на практике очень часто продолжительность работ по этапу намного больше. Значит нужно каким-то образом оценить производительность участников проектной команды без видимого результата их работы. Всё было бы просто, если бы труд программиста можно было бы пронормировать подобно труду другого исполнителя, например, каменщика или токаря (выточил N болванок в соответствии с плановым заданием и без брака - вот и молодец). Но с программистом такой простой аналогии не получается... Конечно, можно пронормировать количество написанных операторов за период времени, но как оценить их качество, если конечного продукта ещё нет? С работой бизнес-аналитика ещё сложнее - там вообще нечего проверять до момента появления версии документа - эскизного или технического проекта. А если учесть тот факт, что при разработке используется итерационный метод, предполагающий возможность возврата к предыдущим и, казалось бы, завершённым шагам проекта для доработок, то задача адекватной оценки результата на текущую дату ещё более усложняется.
Однако, Ваши рекомендации внушают оптимизм. Если можно разбить любой этап проекта на отдельные составляющие с длительностью в несколько часов, то, вероятно, можно оценить и выполнение по каждой из этих составляющих. Практческое применение такого метода для оценки результативности труда тестера или технического писателя представляется вполне возможным. Но как быть с другими участниками проекта, такими как бизнес-аналитики и программисты? Я думаю, что многое прояснится, если Вы приведёте пример возможного описания реального проекта с детализацией этапы проекта (последовательность работ "от начала и до конца") с заданным шагом, например, в 2 часа. Думаю, что будет достаточно примера всего лишь одного этапа, например, "Разработка эскизного проекта". Сразу оговорюсь, эта просьба связана не с моими сомнениями в возможности такой детализации, а с уверенностью в том, что наши руководители проектов не готовы к ответу на этот вопрос.
Таким образом, если нам удастся прийти к пониманию поддающихся измерению "элементарных составляющих" труда всех членов проектной команды, то использование показателя "Результативность по времени реализации проекта" станет понятным. Согласен с Вами в том, что это основной критерий. Критерий "Результативность по качеству" понятен, впоследствии можно будет обсудить возможные способы его практического применения.
С уважением,
Александр.
Уважаемый Александр!
Добавлю деталировки к примеру Кирилла (как это делается у нас в компании). Обратите внимание на деталировку по русски в примере N.
Задача 1 | Нормативное время, мин | Что на выходе |
Написать техническое задание | 300 (5 часов) | ТЗ по стандарту (указать) |
Введение, основание и назначение разработки | 30 | Раздел по стандарту (указать) |
Описание функциональных требований | 30 | Раздел по стандарту (указать) |
Описание первичных требований к структуре данных | 60 | Раздел по стандарту (указать) |
Описание требований к производительности | 60 | Раздел по стандарту (указать) |
Описание требований к надежности | 30 | Раздел по стандарту (указать) |
Описание условий эксплуататции | 30 | Раздел по стандарту (указать) |
Описание требований к ТС | 30 | Раздел по стандарту (указать) |
Описание требований к совместимости | 30 | Раздел по стандарту (указать) |
Примечания:
| ||
Задача 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. Допустим мы озадачим программиста написанием определённых кодов за определённое время, но как оценить его работу, если за отчётный период коды так и не превратились в программу?
С уважением,
Александр.
Уважаемый Александр!
В начале позволю себе общее замечание - Ваш пример оценки сложности работы программиста неким прорабом как нельзя лучше показывает то, что для адекватной оценки чего-либо необходимо, если не быть профессионалом в данной области, то, по крайней мере, понимать оцениваемый предмет. К чему, собственно, я и стремлюсь.
Верно. Поэтому не стоит делать такие сравнения: вот есть работа программиста и он сложна и многофакторна. А вот есть работа (цит.) каменщика, токаря, ...... и т.д. - они простые и понятные. Будем уважать другие профессии - тем более, что задачи администрирования там тоже весьма нетривиальны.
Теперь мои мысли в связи с Вашим последним ответом. Насколько я понимаю, любой сколь угодно сложный и длительный этап проекта можно разбить на простые шаги длительностью не более 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 - ?
С уважением,
Александр.
Уважаемый Александр!
Таблицу Вашу вижу. Отвечу позже.
Эталонная производительность "по разработке заработных плат" в нашей компании = 4 должности в день. Чистого времени на предыдущие 3 сообщения Вам я затратил 20 минут.
Спасибо,
Здравствуйте, Сергей!
Вы пишете: Чистого времени на предыдущие 3 сообщения Вам я затратил 20 минут.
Приводя свой пример о нашей совместной работе я имел в виду не то, что мы слишком долго занимаемся решением данной задачи, а то, что в момент написания моей реплики задача ещё не решена и именно в этот момент времени сложно оценить результативность нашей работы. Этим я хотел показать, что для любого процесса и любого детального шага проекта всё будет зависеть от периода оценок (Т) - по всей видимости, необходимо соблюдать условие завершения итерации по шагу впределах Т. Таким образом, задача может быть решена, если удастся определить шаги проекта с длительностью не более определённого временного интервала, и имеющие свои собственные результаты, поддающиеся количественной и качественной оценке, не так ли? Кстати говоря, тот факт, что при суммарных затратах времени на написание сообщений в пределах нескольких часов сам процесс длится уже несколько дней, подтверждает значительное влияние коммуникаций на процесс работы проектной команды. Само по себе это ничего не опровергает, но подтверждает зависимость процесса не только от производительности исполнителей, но и от многих других параметров.
Вы пишете: Эталонная производительность "по разработке заработных плат" в нашей компании = 4 должности в день.
Здесь Вы имеете в виду, что существуют нормативы производительности труда для всех ролей участников проекта?
С уважением,
Александр.
Уважаемый Александр!
Кстати говоря, тот факт, что при суммарных затратах времени на написание сообщений в пределах нескольких часов сам процесс длится уже несколько дней, подтверждает значительное влияние коммуникаций на процесс работы проектной команды.
Да, ничего он не подтверждает. Просто у меня сейчас стажировка и 32 Клиента одновременно. Соответственно, выкраиваю время.
Здесь Вы имеете в виду, что существуют нормативы производительности труда для всех ролей участников проекта?
Существует прописанная технология разработки и нормативное время на каждый ее этап. Участники проекта получают задания (каждый свое), которые и выполняются.
Спасибо,
Здравствуйте, Сергей!
Вы неверно поняли смысл моего замечания относительно затрачиваемого нами времени. Меня впечатляет оперативность Вашей реакции с учётом Вашей занятости, и за это хочется сказать отдельное "СПАСИБО". При этом я полагаю, что если суммарно Вы затратили всего 20 минут на написание сообщений, то это суперрезультативно! Но дело не в этом... Суть моей мысли заключается в том, что для работы в команде требуются коммуникации между участниками проекта, а это требует времени. Следовательно, конечный результат зависит не только от производительности каждого из нас, взятого в отдельности. И чем больше проект, чем больше членов в команде, тем больше времени будет затрачено на необходимые коммуникации. Это не требует доказательств, так как является объективной реальностью. Вот и всё.
Дабы не уйти в сторону от обсуждения основной темы я предпочёл бы вернуться к вопросу по обозначенному Вами шагу 3. Надеюсь, ответ на него многое прояснит.
С уважением,
Александр.
Уважаемый Александр!
Одно небольшое уточнение перед тем, как мы перейдём непосредственно к примеру проекта - я считаю себя профессиональным менеджером, но никак не программистом.
ОК. Будем считать, что я и сам такой.
Поэтому я пока буду отвечать, как менеджер получивший Ваш проект на экспертизу. Ниже: беспокойства по плану, еще ниже: предложения.
Беспокойство 1. Имею стереотип о том, что этот план сильно "надут".
1.2.1. | Определение структуры входных и выходных данных. | 08.02.2007 | 16.02.2007 |
Спасибо,
Здравствуйте, Сергей!
Описанные Вами "беспокойства" полностью соответствуют моим. Более того, в работе руководителя проекта проявляются признаки, свидетельствующие либо о его недостаточной компетенции, либо о попытках манипулирования инвестором. Насколько я понимаю, любой план, составленный руководителем проекта - профессионалом, должен быть детализирован по шагам, соответствующим определённым работам, которые могут и должны быть завершены в течение нескольких часов, а результат этих работ должен быть видимым и поддаваться количественной и качественной оценке. Если так, то неспособность руководителя проекта составить подобный план будет свидетельствовать о его несоответствии занимаемой должности, а успешное составление детального плана позволит обеспечить жёсткий контроль над исполнением проекта и выстроить систему мотивации таким образом, чтобы исключить возможность манипулирования со стороны проектной команды. Мои выводы верны?
Теперь о предложениях.
1. Проблема отсутствия зафиксированных требований к назначению и функциям программы в нашем случае не актуальна. Требования заказчика сформулированы в заявке на открытие проекта и детально описаны в техническом задании. К сожалению, здесь я не могу предложить к обсуждению подробности, т. к. в настоящее время идея проекта является конфиденциальной информацией. Надеюсь, это никак не помешает нам перейти к следующему предложению, т. к. принципы построения рабочего плана проекта не должны зависеть от его специфики, не так ли?
2. Мне тоже очень не нравится не детализированные шаги проекта, особенно в случае их длительности более месяца. На предложение сделать детализацию по всем этапам проекта с шагом, если не несколько часов, то хотя бы несколько дней, руководитель проекта отвечает приблизительно следующее: "Я могу сделать любую детализацию на этапах технического и рабочего проектов, но не могу запланировать ничего более определённого на этапе эскизного проекта, т. к. здесь мы заняты научными изысканиями, а наука - это предмет тёмный и детальному планированию не подлежит". Меня подобная аргументация не убеждает, но как доказать обратное? Вы рекомендуете дать поручение "разделить пункт на этапы" тем самым отвечая на вопрос "Что делать?". Но в тупик заводит вопрос "Как это сделать?". Именно поэтому я предлагал показать подобную детализацию шагов, соответствующим реальным задачам этапа "Разработка эскизного проекта" для реального проекта. По сути, для меня такой образец может стать решающим аргументом в пользу того, что подробная детализация плана возможна и необходима.
С уважением,
Александр.
Уважаемый Александр!
На предложение сделать детализацию по всем этапам проекта с шагом, если не несколько часов, то хотя бы несколько дней, руководитель проекта отвечает приблизительно следующее: "Я могу сделать любую детализацию на этапах технического и рабочего проектов, но не могу запланировать ничего более определённого на этапе эскизного проекта, т. к. здесь мы заняты научными изысканиями, а наука - это предмет тёмный и детальному планированию не подлежит".
У каждого исследования существует какая-то цель. Например, цель Г.С. Альтшуллера, поставленная при создании ТРИЗ - это упростить процесс решения изобретательских задач. Точно так же целью Франсуа Виета было упростить решение уравнений первых четырех степеней. Поэтому должна быть определенная цель (или гамма целей) и у эскизного проекта. Например, в нашем случае такими целями было:
Подобные цели должен привести и Ваш менеджер проекта.
Вы рекомендуете дать поручение "разделить пункт на этапы" тем самым отвечая на вопрос "Что делать?". Но в тупик заводит вопрос "Как это сделать?".
Можно применить такой прием:
С уважением,
Уважаемый Александр!
т. к. здесь мы заняты научными изысканиями, а наука - это предмет тёмный и детальному планированию не подлежит.
Такое может говорить человек, наукой не занимавшийся. Я бы с ним не спорил, а отправил с богом.
Подробнее отвечу чуть позже. К рекомендациям Кирилла Лебедева - присоединяюсь.
Спасибо,
Здравствуйте, Кирилл!
Ваши рекомендации понятны. Наше обсуждение заставило меня обратиться к нашим внутрифирменным стандартам процесса разработки ПО. Последние сомнения развеялись - оказалось, что при составлении планов эти стандарты в части детализации этапов по шагам не соблюдены. Будем наводить порядок и, я уверен, мы ещё вернёмся к продолжению обсуждения. Сейчас я прихожу к заключению, что на время нужно отложить решение зарплатной задачи, т. к. выявляется более серьёзная корневая проблема. Большое спасибо за участие, Вы оказали действенную помощь.
С уважением,
Александр.
Здравствуйте, Сергей!
Как я уже отметил в ответе Кириллу, мои вопросы относительно возможности детализации любых этапов любого проекта сняты. По всей видимости зрелость процесса разработки ПО у нас сейчас соответствует характеристике "стандарты приняты, но не соблюдаются". Думаю, что прежде всего следует навести порядок в этом отношении. Если Вас не затруднит, я просил бы оценить принятые у нас требования к составлению планов:
А также:
Таким образом, я полагаю, что для наших проектов с предполагаемым сроком от 1 до 1,5 лет длительность элемента декомпозиции не должна превышать 5 дней (по крайней мере, к моменту начала работы по очередному этапу проекта), а суммарное количество элементов плана, соотвтетствующих определённым мероприятиям, не может быть меньше 100 (по крайней мере, к моменту перехода к заключительным этапам). Скорее всего, в этом случае автоматически снимется вопрос по отсутствию в плане специфики проекта, да и многое другое.
На данном этапе мне ясны первоочередные задачи, но если Вы сочтёте возможным дать какие-либо рекомендации, я буду готов к продолжению наших консультаций. Надеюсь, мы несколько позднее вернёмся к продолжению обсуждения проблемы решения зарплатной задачи, а текущие результаты окажутся интересными и полезными уважаемым коллегам. Спасибо за оказанную помощь.
С уважением,
Александр.
Уважаемый Александр!
Большое спасибо за участие, Вы оказали действенную помощь.
Пожалуйста! Рад, если мои рекомендации оказались полезны.
С уважением,
Уважаемый Александр!
Как я уже отметил в ответе Кириллу, мои вопросы относительно возможности детализации любых этапов любого проекта сняты. По всей видимости зрелость процесса разработки ПО у нас сейчас соответствует характеристике "стандарты приняты, но не соблюдаются". Думаю, что прежде всего следует навести порядок в этом отношении.
ОК.
"В качестве элементов декомпозиции используются работы или мероприятия, характеризующиеся хотя бы одним из следующих признаков:
Хотя диапазон задан Вами достаточно жестко (только на очень длинных проектах могут пойти "разбросы"), я бы рекомендовал указывать не относительные значения (т.е., % в Вашем случае), а абсолютные - т.е., буквально нормо-часы. Иначе Вы будете отводить разное время на одни и те же работы (в зависимости от того, в рамках какого проекта (длинного или короткого) они выполняются). А - собственно говоря - почему? Работа, которая должна быть выполнена за 2 часа должна быть выполнена за 2 часа независимо от того, сколько длится весь проект.
Поэтому просто установите предел (шаг) описания: например, 2 часа. Постепенно, это приведет к тому, что у Вас начнет накапливаться "Справочник работ" (и соответствующие нормы времени).
Таким образом, я полагаю, что для наших проектов с предполагаемым сроком от 1 до 1,5 лет длительность элемента декомпозиции не должна превышать 5 дней (по крайней мере, к моменту начала работы по очередному этапу проекта), а суммарное количество элементов плана, соотвтетствующих определённым мероприятиям, не может быть меньше 100 (по крайней мере, к моменту перехода к заключительным этапам). Скорее всего, в этом случае автоматически снимется вопрос по отсутствию в плане специфики проекта, да и многое другое.
По крайней пере, на первых этапах (НИР, эскизное проектирование...) установите шаг в 2 часа. Я повторяю это не из догматизма и даже не из желания ускорить эти этапы, а, как раз, потому, что такой принцип вынуждает (в самом хорошем/продуктивном смысле этого слова) действительно думать над проектом, выделять ключевые задачи, находить заранее и описывать "смутные места" проекта. Потому, что когда разработчик говорит: "Я не могу данную задачу разделить на короткие подзадачи - это значит, что вот это самое "смутное место" он должен вынести и описать/объявить/разобрать отдельно". (Это показал в своем примере Кирилл Лебедев).
Но, если мы оперируем длительными интервалами, то о многих реальных серьезных задачах даже и не задумаются. Их не увидят, "проскочат"... . В итоге, "архитектура проекта" (и не только) рискует оказаться плохой и это потом очень сильно аукнется (а то и взорвется) на последующих этапах (в том числе, на последних). А ведь исправлять архитектурные баги большого проекта на последних этапах - это почти смерть.
Спасибо за оказанную помощь.
ОК. Спасибо и Вам,
Здравствуйте, Сергей!
Ваши рекомендации понятны, но в связи с ними у меня возникли 2 вопроса:
1. Возможно я не вполне верно представляю различия между большим и малым проектами, но мне казалось, что вполне уместно провести аналогию, например, с возведением большого и малого здания - если и для большого, и для малого потребуются одноимённые этапы (например, устройство фундамента), то можно предположить, что на устройство большого уйдёт пропорционально (а может быть даже непропорционально) больше материалов и времени, чем на аналогичную работу для малого. Поэтому мне кажется обоснованной привязка длительности шага к сроку проекта в целом, ведь несмотря на то, что работы могут быть аналогичными, их объём всё же может отличаться от проекта к проекту. В чём я ошибаюсь?
2. Вы пишете:
Постепенно, это приведет к тому, что у Вас начнет накапливаться "Справочник работ" (и соответствующие нормы времени).
Подобный справочник уникален для каждого разработчика, либо существуют соответсвующие нормативные документы подобно ГЭСН в строительстве? Если существуют, прошу дать ссылку. Если не существуют и речь идёт о том, что каждый разработчик должен накапливать собственную статистику и сам устанавливать для себя нормативы, то могу ли я рассчитывать на Вашу помощь?
С уважением,
Александр.
Уважаемый Александр!
Возможно я не вполне верно представляю различия между большим и малым проектами, но мне казалось, что вполне уместно провести аналогию, например, с возведением большого и малого здания - если и для большого, и для малого потребуются одноимённые этапы (например, устройство фундамента), то можно предположить, что на устройство большого уйдёт пропорционально (а может быть даже непропорционально) больше материалов и времени, чем на аналогичную работу для малого. Поэтому мне кажется обоснованной привязка длительности шага к сроку проекта в целом, ведь несмотря на то, что работы могут быть аналогичными, их объём всё же может отличаться от проекта к проекту. В чём я ошибаюсь?
Вы пишете: Постепенно, это приведет к тому, что у Вас начнет накапливаться "Справочник работ" (и соответствующие нормы времени). Подобный справочник уникален для каждого разработчика, либо существуют соответсвующие нормативные документы подобно ГЭСН в строительстве? Если существуют, прошу дать ссылку. Если не существуют и речь идёт о том, что каждый разработчик должен накапливать собственную статистику и сам устанавливать для себя нормативы, то могу ли я рассчитывать на Вашу помощь?
Здравствуйте, Сергей!
Спасибо за детальные разъяснения.
Из Вашего ответа на 1-й вопрос я делаю вывод о том, что далеко не для всех этапов и шагов проекта существует прямая зависимость между масштабом проекта и длительностью этапа. В связи с этим, корректную экспертную оценку плана с учётом технологии и особенностей соответствующих процессов, может сделать только профессионал с глубокими знаниями в предметной области данного проекта и опытом работы в проектных командах. Поэтому следует задаваться абсолютными значениями человеко-часов, рассчитанными не относительно некого предположительного срока проекта, но на основании нормативов по соответствующим видам работ. Я верно формулирую? Я полностью согласен с тем, что необходимо проводить максимально возможную детализацию рабочих планов как с целью повышения точности планирования, так и для недопущения искусственного "раздувания" планов. Что касается процедуры планирования, то я не вижу существенного противоречия в том, что первоначальный план может быть сделан как "снизу-вверх", так и "сверху-вниз". Просто, если после планирования "сверху-вниз" длительность шага превысит, например, 1% от срока всего проекта, то следует задуматься о дальнейшей детализации, либо о сокращении длительности самого шага.
Из вашего ответа на 2-й вопрос можно понять, что для проектных работ по разработке программного обеспечения в настоящее время элементных сметных норм не существует. Однако, в стадии разработки находится авторская методика под названием "алгоритм эффективной разработки программных систем". Скорее всего, здесь Вы имеете в виду некий стандарт, который в высокой степени формализует процесс разработки? Понимаю, что сейчас разрабатываемый алгоритм находится в "сыром" выде, но если информация о нём не является закрытой, то впоследствии для меня было бы очень интересно понять, каким образом будет упрощён вопрос о нормировании?
С уважением,
Александр.
Уважаемый Александр!
Из Вашего ответа на 1-й вопрос я делаю вывод о том, что далеко не для всех этапов и шагов проекта существует прямая зависимость между масштабом проекта и длительностью этапа.
Это верно. Например, написание слова "например" не займет больше времени, если вот это предложение, которое я пишу будет длинным-предлинным. Я могу потратить больше времени, размышляя о том не написать ли, например, вместо "например", слово "допустим" и также над тем, коряво или нет будет звучать предложение в этом случае и т.д. Но эти затраты времени никак не связаны с длиной предложения.
В связи с этим, корректную экспертную оценку плана с учётом технологии и особенностей соответствующих процессов, может сделать только профессионал с глубокими знаниями в предметной области данного проекта и опытом работы в проектных командах.
Ну, вот это один из приемов (разделение работы на короткие интервалы (например, 2 часа)), который упрощает требования к квалификации менеджера (но не в целом относительно предметной области, а только для частной задачи = понимания продолжительности и уровня (сложности) работы ).
Из вашего ответа на 2-й вопрос можно понять, что для проектных работ по разработке программного обеспечения в настоящее время элементных сметных норм не существует.
Я просто не знаю. Предполагаю, что их нет, но, конечно, могу ошибаться.
Понимаю, что сейчас разрабатываемый алгоритм находится в "сыром" выде, но если информация о нём не является закрытой, то впоследствии для меня было бы очень интересно понять, каким образом будет упрощён вопрос о нормировании?
Да, он в разработке, но появится, конечно.
Спасибо,
Уважаемый Александр!
"Понимаю, что сейчас разрабатываемый алгоритм находится в "сыром" выде, но если информация о нём не является закрытой, то впоследствии для меня было бы очень интересно понять, каким образом будет упрощён вопрос о нормировании?"
Дело в том, что основное время при разработке софта тратится не на программирование как таковое (т.е. написание кода), а на продумывание. Именно поэтому софтверные компании уже давно отказались от измерения производительности труда программиста в строчках кода. Разрабатываемый алгоритм позволяет упорядочить процесс продумывания.
Наиболее частой ошибкой, которую совершают программисты при работе над проектом, является смешение этапов постановки задачи, проектирования и написания кода в один этап. К сожалению, в компаниях, где я работал, было принято работать именно так. Многие программисты думают "в коде" и поэтому обнаруживают проблемы не на этапах постановки задачи и проектирования, а при написании кода. Как результат, это приводит к многочисленным ошибкам и "заплаткам" в коде, и через какое-то время (весьма непродолжительное!) этот код становится невозможно сопровождать. Разрабатываемый алгоритм четко разделяет эти этапы. Каждый этап разбивается на шаги, а шаги содержат не только описания цели (того, что нужно сделать), но и описания приемов (т.е. как это сделать).
Следуя этому алгоритму, программист разбирает задачу шаг за шагом - так что всегда можно оценить, где он находится, сколько он сделал и насколько качественно он выполнил работу. Шаги можно нормировать. Так что проделанную и оставшуюся рабту всегда можно оценить в нормо-часах.
С уважением,
Уважаемые Коллеги!
Дело в том, что основное время при разработке софта тратится не на программирование как таковое (т.е. написание кода), а на продумывание.
Если он не сачкует, не занимается ленью второго уровня, не делает боковиков...
Следуя этому алгоритму, программист разбирает задачу шаг за шагом - так что всегда можно оценить, где он находится, сколько он сделал и насколько качественно он выполнил работу. Шаги можно нормировать. Так что проделанную и оставшуюся рабту всегда можно оценить в нормо-часах
И тогда мы сможем быть уверены, что загрузили его оптимально, что он точно не сачкует, не занимается ленью второго уровня и не делает боковиков... А основное время при разработке софта действительно тратится на продумывание и продумывание это продуктивное.
Спасибо,
Здравствуйте, Кирилл!
Вы пишете: Дело в том, что основное время при разработке софта тратится не на программирование как таковое (т.е. написание кода), а на продумывание. Именно поэтому софтверные компании уже давно отказались от измерения производительности труда программиста в строчках кода. Разрабатываемый алгоритм позволяет упорядочить процесс продумывания.
Именно поэтому я настойчиво задавал вопросы в проекции на этапы проектирования, но не на этапы разработки. Проблемы решаемой мной задачи во много связаны с измерением "эффективности продумывания" в режиме реального времени. По-моему, мы приходим к однозначному пониманию того, что измерить и оценить можно только достаточно хорошо формализованный процесс (описанный в алгоритмическом виде). В этой связи ведущуюся вами разработку в случае успеха будет трудно переоценить. Желаю Вам и вашей команде этого, а также и других успехов!
С уважением,
Александр.
Уважаемый Александр!
По-моему, мы приходим к однозначному пониманию того, что измерить и оценить можно только достаточно хорошо формализованный процесс (описанный в алгоритмическом виде).А раз результаты труда будут измеряемы, то можно будет создать такую модель заработной платы, которая будет стимулировать производительность и соблюдение технологии.
Желаю Вам и вашей команде этого, а также и других успехов!
Благодарю за теплые пожелания! :)
С уважением,
Именно так! Круг замкнулся и всё встало "на свои места". Основные функции менеджмента: планирование, организация, мотивация и контроль. Если процесс не поддаётся планированию, то он неорганизован и бесконтролен, а о мотивации в этой связи вообще говорить не приходится. Так называемые "творческие" процессы - это некий "чёрный ящик", который нужно сделать прозрачным. Если ваш алгоритм позволит сделать это для процессов создания программных продуктов, то само по себе это станет ответом на вопросы, поставленные в этом обсуждении. Ещё раз хочу выразить свою заинтересованность в ознакомлении с результатами вашей работы, как только таковые появятся.
С уважением,
Александр.
Здравствуйте, Кирилл!
Сергей, добрый день!
Мы значительно продвинулись в составлении детальных планов, хотя процесс оказался довольно болезненным и долговременным. Надеюсь, что в ближайшем будущем можно будет вернуться к обсуждению практических аспектов первоначально поставленной задачи. Сейчас, если вас не затруднит, прошу дать ответ на вопрос, который, скорее всего известен вам, как опытным практикам. А именно, возможна ли ситуация, при которой специалисты, составившие техническое задание и эскизный проект не способны к написанию технического проекта? Или, другими словами, является ли нормальной организационная схема проекта, в которой функциональные обязанности одних специалистов ограничены техническим заданием и эскизным проектом, а других - техническим проектом?
С уважением,
Александр.
Уважаемые коллеги, добрый день!
Спасибо за ваши ответы. Из них я понял следующее:
1. Из ответа Сергея можно выделить утверждение о том, что независимо от способностей членов проектной команды, процесс создания программного продукта следует разделить между исполнителями на независимые уровни:
- создания концептуальной модели (ТЗ и эскизный проект),;
- разработки технологии решения (технический проект);
- непосредственно программирование (рабочий проект+тестрование).
2. Из ответа Кирилла я делаю вывод о том, что разделение процесса на операции (постановка задачи, проектирование, разработка алгоритма, разработка технологии, написание кода, тестирование), бесспорно, полезно, но возможно только при определённом уровне опыта и квалификации членов проектной команды, так как в противном случае на практике наблюдаются определённые проблемы в связи с отсутствием взаимопонимания в "пограничных" областях знаний.
Думаю, что я должен уточнить формулировку своего вопроса. Если в нашем случае руководитель проекта мотивирует несоблюдение календарного плана проекта на этапе технического проекта отсутствием системного аналитика, но при этом этап эскизного проекта успешно завершён в срок, то подобное объяснение можно считать "отмазкой", или действительно, специалист, успешно выполнивший эскизный проект, вполне может быть неспособным к написанию технического проекта?
С уважением,
Александр.
Уважаемые Кирилл и Сергей!
Вы подтвердили мои предварительные выводы, что добавило мне уверенности в их правильности. Почти буквально эти же вопросы поставлены перед руководителем проекта - предметные ответы вызывают затруднения. Будем разбираться...
Буду вам весьма признателен, если сможете ответить ещё на один мой вопрос - для выполнения каких специфических задач обычно требуется системный аналитик на стадии технического проекта и чем эти задачи принципиально отличаются от задач на стадии эскизного проекта?
С уважением,
Александр.
Здравствуйте, Кирилл!
Большое спасибо за Ваш предельно понятный ответ и согласие проводить эти консультации. Надеюсь, что в ходе реализации проекта нам удастся найти решение и для первоначально поставленной зарплатной задачи, и для многих других "узких мест" в управлении проектами. Буду очень рад, если этот процесс окажатся полезным не только для меня, но и для Вас, а также для других уважаемых коллег.
С уважением,
Александр.
Уважаемый Сергей Валерьевич!
Уважаемые Коллеги!
По результатам полученного за 5 последних лет опыта хотел бы кое-что добавить и кое-где изменить свою точку зрения.
Я всё же склоняюсь к тому, что основных критерия три: