Постановщик задач

← →
Nous Mellon © (2004-10-10 16:05) [0]

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

← →
jack128 © (2004-10-10 20:15) [1]

Nous Mellon © (10.10.04 16:05)
А может это тот самый project-manager в суть деятельности которого меня любезно посвятили Сергей Маслов и Шарк?
Линк не кинешь??

Но судя по названию, ПЗ - это человек, составляющий ТЗ.

← →
Nous Mellon © (2004-10-10 20:17) [2]

> Линк не кинешь??

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

Возможно, но это очень обобщенно. Меня интересуют именно подробности работы и требования.

← →
Nous Mellon © (2004-10-10 20:24) [3]

Жаль, поиск результатов не дал.
Но там было всего два поста поэтому перескажу:
Сергей как менеджер проекта занимается тем что набрасывает основной ТЗ,
стоит некий алгоритм-схему этапов разработки программы, набрасывает основные куски(около 300тыс. строк(!!!!) ), рассчитвает срок(умножает на три) и распределяет задачи между подчиненными, координируя их действия.
В общем работка тяжелая, особенно учитывая что приходиться много отбраковывать и часто проще сделать самому чем бесконечно объяснять, но тем не менее интересная.

← →
Nick Denry © (2004-10-10 20:52) [4]

(задумчиво и испуганно): Да....

← →
Сергей Суровцев © (2004-10-10 21:00) [5]

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

← →
Nous Mellon © (2004-10-10 21:06) [6]

> потом (или вместе с тем) освоить логику мышления программиста
> как такогого

Непонятно зачем осваивать если сам программист. Достаточно спросить у самого себя как и почму я делаю. :) Другое дело что и уровни мышления у программистов разные.

← →
jack128 © (2004-10-10 21:06) [7]

Nous Mellon © (10.10.04 20:24) [3]
Сенкс.

> набрасывает основные куски(около 300тыс. строк(!!!!) > ),

? В смысле этим занимается Сергей или менеджер проэкта? Просто сложно представить, чтобы project-manager Word"a набрасывает основные куски ;-)

← →
Nous Mellon © (2004-10-10 21:08) [8]

> ? В смысле этим занимается Сергей или менеджер проэкта?
> Просто сложно представить, чтобы project-manager Word"a
> набрасывает основные куски ;-)

Этим занимается Сргей наравне с другими менеджерами проектов. У Ворда может быть другое кол-во строк, но там куча других специфических проблем, например интеграция с основным пакетом, VBA... Так что думаю у него кода не меньше :)

← →
jack128 © (2004-10-10 21:10) [9]

Nous Mellon © (10.10.04 21:06) [6]
Непонятно зачем осваивать если сам программист.

Не, ты не понял. ПЗ - это НЕ программист. Он вообще(как я понимаю) может не знать ни одного ЯП, его задача не в этом.

← →
Nous Mellon © (2004-10-10 21:11) [10]

2jack
Или может ты путаешь project-manager и PR-manager или менеджера по продажам? Или я чего-то не понимаю...

← →
Piter © (2004-10-10 21:12) [11]

Тема: http://delphimaster.net/view/14-1094850210/
(в настоящее время уже удалена)

Цитирую:

----------------------------------------------------------------
Sergey_Masloff (12.09.04 22:04) [73]
Nous Mellon © (12.09.04 21:55) [72]
Нет. Так как я микроменеджер то я должен изучить требования, прикинуть сроки, умножить то что получилось на 3, округлить в большую сторону до месяцев, набросать план проекта (хотя бы пару страниц на бумаге), схему данных и основу ядра (тысяч 150 строк). Потом нужно поручать реализацию отдельных частей другим программистам, собирать тестовые и релизные версии, контролировать сроки и читать что программисты понаписали. Еще нужно сдерживать себя чтобы не переписывать все то что они написали заново. Еще нужно по нескольку раз объяснять что конкретно я хотел видеть от данного конкретного модуля и с тоской думать что быстрей было б самому написать. Еще нужно контактировать с тестированием и службой поддержки (но с этим мне повезло - там просто отличные спецы, я даже не могу оценить их вклад, но это ОЧЕНЬ много. Программисты тоже хорошие но плохо могут в мейнстриме работать. Все пытаются привносить супер-пупер новые идеи. Приходится душить. Но кстати тоже прогрессируют так что еще пару лет и будет очень сильная группа. Если все удастся ;-)
----------------------------------------------------------------

P.S. На правах рекламы - пользуйтесь поиском Magic Forum"а :)

← →
Nous Mellon © (2004-10-10 21:14) [12]

> [11] Piter © (10.10.04 21:12)

Интересно биотоки существуют? :)
Ведь чесслово хотел ведь к тебе обратиться помня наш спор про поиск :)

← →
Nous Mellon © (2004-10-10 21:15) [13]

2Piter
Тем не менее был еще один пост где строк было 300 тыс. :)

← →
Nous Mellon © (2004-10-10 21:17) [14]

Вот он нашел. Там не те 300тысяч :)

--

На самом деле я сейчас параллельно принимаю участие в 2 проектах. Ну мы типа отдела АСУ поэтому трудно сказать два это разных проекта или части одного. В первом (большом ~2.5 млн. строк) я один из разработчиков. Во втором - (маленький ~300 тыс.) я типа менеджер, ведущий программист и постановщик в одно лице. Плюс у меня 1 программист на постоянной основе и по мере необходимости привлекаю на локальные задачи народ. Ну и как уже сказал группа сопровождения но они только поддержка и тестирование и непосредственно я ими не руковожу (и не непосредственно тоже). Так что думаю термин микроменеджер самое для меня ;-)
А про число e это заниженная оценка. Правда я сам пишу медленно довольно, так что может только для меня e мало ;-)

← →
Sergey_Masloff (2004-10-10 21:22) [15]

jack128 © (10.10.04 21:06) [7]
Занимается сергей как проджект-менеджер ;-)
Не путай менеджера проекта и проджект-менеджера

Кстати проджект менеджер Excel-а основы набрасывал. И написал немалую часть движка VBA. Ну, по крайней мере он это утверждает. Сейчас ссылку не найду но читал об этом минимум в 2 разных источников коим склонен верить.

Постановщик задачи как программист мыслить ИМХО (и не только имхо) не должен. Более того, ему это вредно. Хорошие постановщики это не бывшие программисты. Вообще не айтишники как таковые. Постановщик не должен знать тонкости программистских технологий он должен иметь общее представление о возможностях. То есть может сказать - мы организуем систему обработки заказов. Основные ее задачи следующие:........ Ее принципиальная схема такая: сервер принимает заказ (за это отвечает подсистема такая-то) пишет в систему контроля (за это отвечает...) потом передается системе XXX для YYY. Как передается, что используется - его особо не волнует. Он допустим знает что есть технология ActiveX но уж про диспинтерфейсы знать - не его дело.
Дело деталей технической реализации - ИМХО дело проджект-менеджера (я иногда для поднятия собственной значимости называю себя sinor programmer. Ну там утром перед зеркалом например ;-)))
Именно это заставляет часто писать много кода с прицелом на корзину - например последние 2 недели я именно этим и занимался. Часа по 3-4 в день естественно, основную работу в это время приходится тоже делать, так что это считай послерабочее время и выходные.
Нет, я не жалуюсь. Мне нравится ;-)

P.S. Естественно я не секретарь-машинистка так что приведенные 300 тыс. строк следует учесть что проекту четвертый год. Это не за неделю же ж.

← →
jack128 © (2004-10-10 21:29) [16]

> Не путай менеджера проекта и проджект-менеджера
а как по английски менеджер проэкта? manager of project? и как по русски project-manager? ;-)

Piter © (10.10.04 21:12) Ну нету у мя в базе этой ветки, что поделаешь??

← →
Palladin © (2004-10-10 21:31) [17]

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

← →
Nous Mellon © (2004-10-10 21:32) [18]

> Проектировщик и постановщик взаимодополняют друг друга.

Лучше если это вообще один человек :)

← →
Nous Mellon © (2004-10-10 21:37) [19]

> [15] Sergey_Masloff (10.10.04 21:22)

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

← →
Sergey_Masloff (2004-10-10 21:38) [20]

Nous Mellon © (10.10.04 21:32) [18]
>Лучше если это вообще один человек :)
Нет. Голова не резиновая. Очень хорошо когда это разные люди.

У меня был краткий опыт с классным постановщиком. Это нечто. Производительность получается просто сумасшедшая. Только постановщиков этих в природе действительно очень мало...

← →
Palladin © (2004-10-10 21:38) [21]

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

PS: диффузия чтоли... ну не физик я! :)
PSS: это все ИМХО. Ибо нет у нас в России, разделения на эти две должности. Обычно все в одном.

← →
Sergey_Masloff (2004-10-10 21:41) [22]

Nous Mellon © (10.10.04 21:37) [19]
>Хорошая работа у постановщика в плане того что не так важны >знания как анлитическо-логические способности. Мне подходит. :)
Знания важны. Но не в программировании. Предметную область знать весьма желательно. То есть постановщик для скажем банковских задач врядли будет столь же хорош в разработке аналога Excel или CAD-системы.

>Шутка. Пока шутка. :)
Ну чтож, как я сказал специальность действительно нужная и дефицитная.

← →
Sergey_Masloff (2004-10-10 21:42) [23]

Palladin © (10.10.04 21:38) [21]
Да, ты, в основном прав. И насчет пользы разделения и насчет что у нас все в одном :(

← →
Nous Mellon © (2004-10-10 21:43) [24]

> [20] Sergey_Masloff (10.10.04 21:38)

А вот насчет аналитическо-логических способностей это так?
> и со стороны формализированной абстракции (постановщика
> задачи).

Вот ключ. Спасибо. Это как в теории множеств - нихрена не понятно пока пример не приведут. Теперь понятно. Это как бы промежуточное звено между
расплывчатыми желаниями заказчика и ТЗ.

← →
Nous Mellon © (2004-10-10 21:46) [25]

> Знания важны. Но не в программировании. Предметную область
> знать весьма желательно. То есть постановщик для скажем
> банковских задач врядли будет столь же хорош в разработке
> аналога Excel или CAD-системы.

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

← →
Palladin © (2004-10-10 21:49) [26]

Менеджеры это МОП. Младший обслуживающий персонал. Только почему то все мендежеры об этом забывают.

← →
Palladin © (2004-10-10 21:53) [27]

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

← →
Nous Mellon © (2004-10-10 21:54) [28]

> Менеджеры это МОП. Младший обслуживающий персонал. Только
> почему то все мендежеры об этом забывают.

А те которые ТОП? ТОП-МОП получается? :)

Ну да. Смысл в том что, как и в НИИ, темы исследований МОПы не касаются. Их задача накормить мышек, поддержать температуру в комнате и постоянное значение влажности :)

← →
Sergey_Masloff (2004-10-10 22:16) [30]

Nous Mellon © (10.10.04 21:46) [25]
>какие вообще должности есть в современном крупном проекте?
Толстой чтоли писал каждая несчастная семья несчастна по-своему. Так ИМХО и с проектами.

Я не такой уж специалист но из того что я наблюдал в голову приходят варианты:
1) У проекта есть "хозяин". Он ведущий программист, постановщик и аналитик. У Брукса они называются "хирургами" чтоли. Он руководит группой, иногда проводит совещания и выслушивает мнения но все решения принимает сам и остальные подчиняются. При хорошем "хирурге" его бригада может работать очень эффективно. Минус - есть потолок выше которого (по масштабам) не прыгнуть. Все же предел возможностям есть, его не может не быть.
2) Проект с "ядром". В центре проекта небольшая команда, как правило, хорошо знающих друг друга разработчиков. Их специализации могут различаться но все они являются и аналитиками и постановщиками и ведущими программистами по направлениям. Кто-то из них выполняет формальную роль лидера-администратора но в решениях влияющих на развитие проекта и ее архитектуру влияют все. Ядро окружено "примкнувшими" программистами которые также являются микроаналитиками и постановщиками но только в рамках определенной "ядром" архитектуры. Методики решения частныхзадач за ними. Ну и еще на внешнем круге - рядовые программисты - кодеры. Часто это недавние студенты и так далее. В нормальных командах их стараются подтягивать и к аналитике - хотя бы и без права голоса но народ растет. Масштаб системы может быть уже очень значительным. Минус - очень велика ценность участников "ядра" - потеря по тем или иным причинам даже двух человек одновременно может стать очень серьезным ударом.
3) По "науке". Руководитель, штат аналитиков и постановщиков (хотя бы 2-4 человека), ведущие программисты по направлениям, ну и дальше иерархия. Ведется серьезная документация, люди не винтики но замена практически любого не так влияет на общий результат. Я видел в действии такой подход только однажды, не впечетлило. На средних проектах ИМХО это не самое эффективное, но на сверхкрупных, наверное, самое то.

> Толстой чтоли писал каждая несчастная семья несчастна по-своему.

твое имхо - мое имхо! (С) Неизвестный индейский прагроммист имени села Майа.

:)))

2Сергей
Моей благодарнгсти нет предела.

> 1) У проекта есть "хозяин". Он ведущий программист, постановщик
> и аналитик. У Брукса они называются "хирургами" чтоли. Он
> руководит группой, иногда проводит совещания и выслушивает
> мнения но все решения принимает сам и остальные подчиняются.
> При хорошем "хирурге" его бригада может работать очень эффективно.
> Минус - есть потолок выше которого (по масштабам) не прыгнуть.
> Все же предел возможностям есть, его не может не быть

Это как в вашем малом проекте?
> сверхкрупных, наверное, самое то.

Как вы оцениваете градцаию проектов? В каких условиях проект крупный, мелкий, средний? Ваше IMHO? Впрочем, можно без H. :)

(Совсем уж страшно стало): Да.......

← →
Sergey_Masloff (2004-10-10 22:53) [34]

Nous Mellon © (10.10.04 22:33) [32]
Ну по крупности проекты делить очень сложно. Буржуйский показатель в 3 млн. строк кода конечно косвенно может что-то сказать.
Ну пойдем по стопам Брукса и определим проекты в мифических человекогодах. Учитываем что крайностей не будет - то есть 1 человек проект обычно не сделает а проект в 300 человеколет за полгода 600 человек тоже не сделает. Итак:
Микро -> Меньше чем малый
Малый: до 1.5 человекогода. Ну то есть трое за полгода.
Средний: до 15 человеколет. То есть проект на год-два
Крупный: до 300 человеколет. Проект года на 3-4. Естественно, такой оплачивать никто не станет он состоит из этапов. Первые реально работающие (внедренные в реальную работу) элементы проекта должны работать МАКСИМУМ через год.
Сверхкрупный -> Больше чем крупный

> (Совсем уж страшно стало): Да.......

Интересно ж е-мое будущее IT. Проекты крупнеют одним ООП уже наглядность и расширяемость не обеспечишь. Людей учавствует все больше...
Организовать это.. вот задача покруче. Мой учитель по программированию когда-то говорил слова, которм я тогда не придал никакого значения, а сейчас вдруг стало ясно, не дословно но все же, во время обсуждения Билла Гейтса.
"Основная заслуга БГ даже не в написании классной ОС как таковой, а в умении организовать работу программистов".

2Nous Mellon © (10.10.04 22:53) [35]

Это все понятно, посто начинают поражать масштабы....

2Sergey_Masloff

Если не ошибаюсь, сударь, вы работаете в данный момент не в России, а в далекой забугории называемой США? Вопрос возник, патамучто, думаю, проекты такого типа нам пока не грозят...

> Если не ошибаюсь, сударь, вы работаете в данный момент не
> в России, а в далекой забугории называемой США? Вопрос возник,
> патамучто, думаю, проекты такого типа нам пока не грозят...

Ингосстрах переехал?

> Крупный: до 300 человеколет. Проект года на 3-4. Естественно,
> такой оплачивать никто не станет он состоит из этапов. Первые
> реально работающие (внедренные в реальную работу) элементы
> проекта должны работать МАКСИМУМ через год.

А как же например тогда Windows за год не сделать рабочий вариант? Даже при 5000 учавст. людей.

← →
Sergey_Masloff (2004-10-10 23:02) [39]

Nick Denry © (10.10.04 22:57) [36]
Ошибаетесь ;-) Самая что ни на есть Россия ;-) см. адрес. Проект я думаю даже чуть больше чем определенный мной как крупный.

> Проект я думаю даже чуть больше чем определенный мной как
> крупный.

То бишь участников > 100? Да тяжелова то, но интересно...

Постановщик задач Найти похожие ветки