Большие проекты. А нужны ли нам аналитики и постановщики задач?

[izx]

Большие проекты. А нужны ли нам аналитики и постановщики задач?

Это тема у меня назревала несколько лет после участия в разработке нескольких проектов связанных с БД на нескольких фирмах.

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

Создается команда из нескольких человек. Одни берут на себя функции постановщиков задачи, другие программистов, которые эту задачу реализуют средствами языков программирования и СУБД.

Предметной области, по моему опыту, при этом не знает никто. Ни программисты, ни постановщики.
У кого есть опыт написания программ – становятся программистами, у кого нет – постановщиками.

Постановщики начинают изучать бизнес правила и пишут техническое задание (ТЗ) на реализацию будущей информационной системы.

Затем ТЗ утверждается и передается программистам, которые пишут по нему программу.

Это в идеале.
Но по моему опыту эта схема работает очень плохо по следующим причинам.

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

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

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

Также есть почва для возникновения конфликтов между программистом и постановщикам.
Программисту может казаться, что его считают не достаточно квалифицированным, раз ему дает указания постановщик.

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

Становится не понятно с кого спрашивать, если при разработке или эксплуатации проекта возникают ЧП.

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

Интересно узнать у кого какой есть опыт коллективной разработки программ?

 

[Crazy]

Re: Большие проекты. А нужны ли нам аналитики и постановщики задач?

Автор оригинала: izx
Предметной области, по моему опыту, при этом не знает никто. Ни программисты, ни постановщики.

Постановщик ОБЯЗАН знать предметную область. Допускается, что он ее не знает в момент старта проекта. И разделение на программистов и постановщиков в правильном проекте проходит именно по этой черте: программист имеет право не видеть общей картины. У постановщика такого права нет.

А то, что ты описал, называется "дармоеды".

 

[Кром]

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

 

[lanka]

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

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

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

> Программисту может казаться, что его считают не достаточно квалифицированным, раз ему дает указания постановщик.

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

> Потому что нужны дополнительные расходы на введение его в курс дела.
> К тому же он чувствует себя не удобно, так как он не учел новые требования изначально в ТЗ.

А почему пользователи контактируют напрямую с программистами? Раз кто-то взялся давать им задания и принимать работу, логично предположить, что именно он будет все показывать пользователям, или сотрудникам, настраивающим ПО, и принимать претензии пользователей, оформляя их в дополнение к ТЗ.
А учесть _все_ в изначальном ТЗ - ну, может быть, и возможно.. Но почему же тогда практически все успешные программные продукты выходят все новыми и новыми версиями?..

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

 

[izx]

Originally posted by lanka
> Ага, а также немедленно начнет разбираться в тонкостях бухгалтерии, нюансах отправки грузов, радостях создания меню и калькуляций в ресторанах, и это все не считая своих родных программистских обязанностей.

На практике программисту приходится во всем этом разбираться

Originally posted by lanka
>
Постановщик наоборот должен быть более квалифицированным, чем простой программист. Он должен разбираться в предметной области, и иметь понятие о программировании. Не "не уметь", а "уметь хорошо", и ставить задачи, тк это сложнее.

Согласен. Должен.
Но я таких постановщиков не встречал.

 

[lanka]

> На практике программисту приходится во всем этом разбираться

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

> Но я таких постановщиков не встречал.

Ну что ж вы - не такие уж и редкие это звери..

 

[deek]

> Но я таких постановщиков не встречал.

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

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

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

В доказательство моих слов, почитайте ИТ прессу, полно новостей о том, как компания "А" отказалась от услуг компании "Б" по внедрению продукта "Х" по причине плохого знания компанией "Б" предметной области компании "А".

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

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

upd:
> Предположим, встала перед компьютерным отделом задача по автоматизации какого-то участка работы на крупной фирме.
> ...
> Предметной области, по моему опыту, при этом не знает никто.

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

 

[inTox]

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

 

[phpdemon]

Насчет ответственности.
У каждого большого проекта должен быть Менеджер проекта (возможно он же и постановщик задач, но лучше разделить эти ф-ции)
Вот он как раз и отвечает за сдачу проекта в срок и в соответствии с требованиями.
А дать каждому девелоперу свой кусок работы от общения с заказчиком и до написания кода, и потом его совместного объединения - верный способ проект завалить.
отвечать за проект и принимать все управленческие решения по нему должен ОДИН человек - Менеджер проекта!
И очень не помешает в проекте при работе со специфической предметной областью системный аналитик, опять таки он может и ставить задачи программистам при согласовании с ПМ

 

[Scarab]

А какое принципиальное отношение здесь к PHP?

Организация работы - это совершенно отдельная тематика, к языкам отношения не имеющая совершенно. Здесь надо смотреть ну хотя бы в сторону RUP. Ну и какие там еще есть способы организации разработок - Extreme Programming, например.

На эту тему давно написаны кучи книжек и материалов. Но это опять-таки область Project Management'а - распределение ролей.

 

[Alexandre]

ТЗ нужно, чтоб сформулировать задачу и утрясти ее с Заказчиком, т.е. обрисовать рамки законченности проекта

Работа без ТЗ превращается в бесконечный цикл отладочных итераций

 

[Alexandre]

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

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

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

 

[FireFalcon]

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

Роли, типа чистый аналитик или чистый архитектор - очень тяжело вписываются в работу команды на практике. Это обычно просто абстракции, на которые делить людей нет особого смысла, особенно в средних и мелких проектах, там где в команде меньше 20 человек.

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

 

[Alexandre]

Роль типа чистый аналитик или чистый архитектор

на практике бывает (сам работал какое-то время в коллективе 15 чел), но аналитик должен обладать всеми необходимыми знаниями и даже более ... чем рядовой программист, а так же знать и вникать в предметную область. Далее он делит задачу на несколько частей и раздает задания кодерам.

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

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

 

[izx]

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

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

Технология что какой то очень умный аналитик разрабатывает гениальное ТЗ, а низко квалифицированные программисты пишут программу – не эффективна.

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

Я реально работал в такой связке и знаю о чем говорю.

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

 

[FireFalcon]

Originally posted by izx

Технология что какой то очень умный аналитик разрабатывает гениальное ТЗ, а низко квалифицированные программисты пишут программу – не эффективна.

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

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

 

[Alexandre]

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

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

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

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

Следующий этап - осмысление накопленых знаний, который может быть выражен как написание ТЗ, или UML диаграмм, или еще как-нибудь.

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

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

Конечно можно держать и одного программиста если он гений и знает специфику национального законодательства в области:
- Таможенного права
- Предпринимательства
- Гражданского законодательства Росиии
- Бухгалтерия
- Нормативной базы по экспедиторству и складскому учету)
Быть вдобавок художником и Дизайнером сайта, а также системный администратором и администратором БД.

Как видите - у каждого должна быть своя роль в проекте. Невозможно объять необъятное.
Маленькие проекты - маленьким людям, Большие - ....

 

[webdeveloper]

Аналитики бывают разные. Например я programmer analyst, а есть business analyst. А есть еще и system analyst.

В разделение работы может происходить вот так(на примере нашей компании):

Business Analyst : Знает досконально конкретный Business process. Например, получение запастных частей для cell towers для нашей компании от поставщиков. Знает чем например работа с Nortell отличается от работы с другими компаниями. Определяет что нужно сделать или изменить в существующем процессе. Составляет задание на проектирование. Если упрощенно то является представителем заказчика. Отвечает за соответствие того что получилось с тем что хотели. Не знает ничего о програмировании.

System Analyst (System Architect) : Разрабаытвает модель системы, совместно с Business Aanalyst собирает requirements. Составляет техническое задание на проект, UML и т.д. Знает и хорошо разбирается в програмировании, как правило в прошлом ведущий програмист. Является связуюзим звеном между теми кто разрабатывает и теми кто будет использовать продукт.

Programmer Analyst(Lead Developer): Основываясь на данных полученных от System Analyst'а разрабатывает отдельные модули. Опытный и грамотный програмист. Досконально знает свою область програмирования. Может иметь в подчинении несколько кодеров. На знает практически ничего о бизнесс процессе кроме самых общих сведений.

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

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

А уж утверждать что это все может сделать один человек, и что это быдет быстрее, это, коллеги, просто смешно. Это 100% признак что не было просто больших и сложных проектов. Ибо всего знать нельзя и "невозможно обьять небьятное" (с)

 

[Screjet]

ИМХО процесс:

[проектирование]
1) Успех проекта зависит от ПРАВИЛЬНО поставленной задачи. Если он не знает, что он хочет (а бывает, что и не горит желанием знать), идет совет с будущим потребителем. Специалист в предметной области задачи помогает заказчику разобраться с задачей. (Это в случае чегото нового и необычного, иначе рассматриваются готовые примеры) Собственно от этого пункта зависит пол-победы.
1-а) Обязательно убедить заказчика в необходимости версионности проекта (причины, думаю ясны )
2) Т.к. задача поставлена правильно, уже можно представить (нарисовать/начертить..) ГОТОВЫЙ результат. Картинки (чертежи, рисунки) предоставляются заказчику и описывается что как работает. На этом этапе заказчик придумывает все новшества/изменения, что придут ему в голову. (рекурсивно повторяем п.1,2 пока заказчик не будет удовлетворен) Утверждаем первую версию заказа.
[планирование]
3) Исходя из задачи, ресурсов, вренеми выполнения (которое должно быть не менее времени проектирования и планирования) вычисляем нужные аргументы (ресурсы либо время выполнения)
4) Дифференциация (так кажись это называется): разбиваем одину большушию задачу на несколько маленьких задач (если нужно - рекурсивно).
5) На каждую мини-задачу уже можно назначать людей (отвественных).
5-а) Отвественные (обычно уже програмеры, дизайнеры и т.д.) огаваривают (обобщают) интерфейс (взаимодействие) мини-задач. (желательно и общие методы реализации мини-задач)
5-б) Поиск нужных библиотек, готового кода (картинок, HTMLя и т.д.), чтоб не делать лишней работы. (Каких-то новшеств пытемся избежать всеми усилиями )
5-в) В это же время мастера БД упорно проектируют БД.
[реализация]
6) БД готова, все модули есть (дизайнеры на старте), можно реализовывать.
[сборка]
Этим обычно занимается самый продвинутый програмер (дизайнер), который может являтся одновременно и руководителем проекта (заместителем/помощником). По мере поступления решенных мини-задач объеденяет все в кучу.
[спецификация]
Если у програмеров код не очень культурный (кривой ООП или вообще без оного), составляется спецификация. ИМХО на нормальный ООП спецификация не нужна, если нет особого требования заказчика. (Обычно этот пункт нужен, чтоб програмеры не скучали по каким либо причинам )

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

 

[sapenov]

Часто бывает так, что business rules в компании-заказчике не отработаны полностью, а иногда и не формализованы вовсе. Это ставит в тупик не только аналитика, но и самого project manager' а. Встречается это как в средних, так и в крупных компаниях. В простонародье называется бардак.
Хороший project manager не возьмется за такой проект изначально.