Здравствуйте, A.Lokotkov, Вы писали:

AL>Здравствуйте, Gaperton, Вы писали:

G>>С переменным успехом. У нас длительный и довольно рискованный проект. Только-только наладили формализованный процесс разработки, он проходит обкатку.

AL>А каким образом в вашем проекте вырабатываются требования к тому, что будет на выходе в конце и на промежуточных этапах? Даже вот так сформулирую вопрос:
AL> — имеется ли ТЗ (или аналог);
Имеется. Для простых изделий оно имеет вид спецификации для разработчика (datasheet). Сначала она очень краткая и приблизительная, и уточняется в ходе работ.

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

AL> — откуда берутся требования для ТЗ (если есть): изнутри организации, извне или так-и-эдак;
Требования собираются во взаимодействии с потенциальными потребителями, одновременно с уточнением объема спроса. Это сложно — необходимо идентифицировать всех участников "пищевой цепочки", и выбрать из них правильные организации для взаимодействия. Например, прямой потребитель (производство), как это не странно, не всегда может являться источником требований для систем на кристалле, которые применяются в их изделиях.

AL> — выработкой требований занимается один оракул (внешний или внутренний) или группа (если группа, то в составе каких специалистов: R&D, кастомеры, маркетинг или как-то иначе);

Выработка требований для продуктов — задача маркетинга. Обычно за требования отвечает product manager, при их составлении и проверке участвуют все типы специалистов, и все типы компаний, завязанные в выбранном нами секторе рынка.

AL> — каким образом принимается решение о "правильности" отдельных требований: кем-то единолично "интуитивно" или иначе и на основании чего;

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

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

AL>Думаю, поработав некоторое в "длительном и довольно рискованном", а также, насколько я понимаю, сложном проекте с большой исследовательской составляющей, Вы вряд-ли отошлете меня к матчасти

Да нет матчасти-то толковой, вот в чем проблема . Рад был бы, если бы меня к ней кто отослал.

AL>Кроме того, мне очень интересно, как Вы оцениваете планируемую длительность (трудоемкость) задач. Оговорюсь, что с "Методом Гапертона", опубликованным на rsdn, я знаком Вопрос в том, насколько и как(!) это применимо в Вашем текущем проекте. Спрашиваю еще и потому, что не очень понимаю, каким образом итерация может продолжаться год и более.

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

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

AL>Наконец, любопытно, до какой степени происходит детализация задач, какова средняя планируемая длительность и удается ли не промахнуться по факту в среднем на группе связанных друг с другом задач (если есть большие промахи, то насколько).

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

AL>По поводу "формализованного процесса" конечно же тоже интересно было бы узнать, как и что, хотя бы на уровне примерного flow с названиями стадий/этапов и артефактов на выходе каждого. Однако ведь не расскажете

Флоу очень близок по принципам построения к RUP. Стадий побольше — из-за специфики разработки аппаратуры.

G>> Недавно корректировали курс, чтобы снизить риски и уложиться с первой итерацией до конца 2007 года по проекту системы на кристалле. Кое-что простое готовим к запуску небольшим тиражом в ближайший месяц-два — всякая мелочевка для военных, типа микросхем элементарной логики, ЦАП и АЦП.

AL>Мелочевка? Им что, какие-то нетрадиционные цап и ацп нужны? Или это вопросы цены и разрешительного перечня?

Это именно вопрос цены и разрешительного перечня .

AL>Просто, насколько мне представляется, сделать, скажем, быстрый цап/ацп с хорошей метрологией и удобными внешними "педалями" довольно сложно, а тем более довести полученное хотя бы до небольших серий.

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

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

AL>Кроме того, скажем, у вас получился классный ацп, но чтобы сделать на нем нормальный измерительный тракт, требуется куча качественной обвески типа ИОН, мультиплексоров, инструментальников, да и просто пассивных компонентов. Их то они иззарубежа что-ли собираются брать?

А хрен его знает. Мне кажется, это уже не наша проблема. Если интересно — у инженеров спрошу в понедельник.

Спасибо за ответы.

G>Да нет матчасти-то толковой, вот в чем проблема . Рад был бы, если бы меня к ней кто отослал.

Я как-то уже приводил ссылку на книжку, которая, по моему мнению, в наилучшей степени обобщает работающие практики управления подобными проектами.

G>"Метод Гапертона" — применим для тим-лидов, и небольших проектов, и разработан, когда Гапертон был тим-лидом. Сейчас у нас есть кое-что получше. Скоро опубликую. В методах прогноза длительности, впрочем, поменялось мало чего.

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

G>Длительность задач порядка недели, а вообще — зависит от характера работ. Насчет точности — могу выложить один из старых отчетов по группе моделирования. Удается, удается — когда уровень риска небольшой, понятно что делать, и сроки не зависят от внешних факторов . У нас такое редко бывает.

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

G>Флоу очень близок по принципам построения к RUP. Стадий побольше — из-за специфики разработки аппаратуры.

А какие появляются специфические стадии, учитывающие наличие co-design-а? У нас практические вся работа -- сплошной co-design, и 99% проблем связано с неудовлетворительной координацией работы разных функциональных подразделений.

G>В микроэлектронике почти не бывает небольших серий. Это экономически не выгодно. А насчет "сложно" — понятия "сложно" в менеджменте нет, есть понятия "рискованно", "долго", и "дорого" . Так вот, наша сувенирная продукция — дешева, низкорискованна, и быстра.

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

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

Согласен.

G>А хрен его знает. Мне кажется, это уже не наша проблема. Если интересно — у инженеров спрошу в понедельник.

Большинство производителей законченных устройств (модулей) аналогового ввода, скажем, для рынка АСУТП, используют одни и те же многоразрядные сигма-дельта АЦП, которые сами по себе имеют очень заманчивые характеристики, как по точности, так и по скорости. Однако точность модулей в большинстве своем не лезет ни в какие ворота и в лучшем случае эквивалентна использованию 9-10 разрядного АЦП. Это же относится и к скорости (времени опроса каналов). Поэтому вам, видимо, придется тщательно разрабатывать референс-дизайн на базе ваших микросхем совместно с разрешенной к использованию дополнительной обвеской и тестировать его вдоль и поперек, в том числе в заявленном диапазоне рабочих температур. Иначе обозначенная проблема станет вашей.

Здравствуйте, peoplewarrior, Вы писали:

Кё>>Ответственность не делится.
P>А вот как вы ответите на такие вопросы:
P>1. Ответственность за профессиональный и личный рост разработчика несет:

Короче, я сначала написал много, а длинные тексты никто не читает, поэтому стёр, написал меньше, стёр, написал мало, стёр, на самом деле я тут напился абсента и спать хочу

1. Ответственность поделить невозможно, ибо она бывает только перед собой. Ответственность перед другим — иллюзия.
2. У каждого свои цели. Единая цель у нескольких человек — иллюзия. Типа профессионального роста разработчика.
3. Sapienti sat.
4. Завтра больше, если не sapient или не sat

Здравствуйте, A.Lokotkov, Вы писали:

G>>"Метод Гапертона" — применим для тим-лидов, и небольших проектов, и разработан, когда Гапертон был тим-лидом. Сейчас у нас есть кое-что получше. Скоро опубликую. В методах прогноза длительности, впрочем, поменялось мало чего.

AL>Буду ждать Ибо приходится одновременно быть руководителем функционального подразделения, тим-лидом и неформально выполнять координирующие функции между разными функциональными подразделениями.

Готово. Методика здесь — http://rsdn.ru/Forum/Message.aspx?mid=2302507&only=1

Автор: Gaperton
Дата: 15.01.07

ЗЫ: Для решения проблем координации:
1) вводишь в план специальный тип целей, которые будут общими для нескольких подразделений.
2) Применяешь на регулярной основе методику перекрестных инспекций дизайна и архитектуры, включая людей разных подразделений в качестве инспекторов. Методика здесь — http://rsdn.ru/Forum/Message.aspx?mid=1358322&only=1

Автор: Gaperton
Дата: 01.09.05

Здравствуйте, Кодёнок, Вы писали:
Кё>1. Ответственность поделить невозможно, ибо она бывает только перед собой. Ответственность перед другим — иллюзия.
Что это, бывает ответственность перед другими, материальная например. Замечательно между прочим делится.
Ответственность перед собой тоже бывает, и тоже прекрасно делится.

Кё>2. У каждого свои цели. Единая цель у нескольких человек — иллюзия. Типа профессионального роста разработчика.
Ерунда, простите. Цель выпустить ближайший релиз едина для всей комманды. И многие другие едины. Есть у каждого и свои собственные никем не разделенные, несомненно. А профессиональный рост разработчика — это не иллюзия. Ну вернее у кого как.

Кё>3. Sapienti sat.
Кё>4. Завтра больше, если не sapient или не sat
Не понял, буквы какие то нерусские.

Здравствуйте, peoplewarrior, Вы писали:

P>Здравствуйте, Кодёнок, Вы писали:
Кё>>1. Ответственность поделить невозможно, ибо она бывает только перед собой. Ответственность перед другим — иллюзия.
P>Что это, бывает ответственность перед другими, материальная например. Замечательно между прочим делится.
P>Ответственность перед собой тоже бывает, и тоже прекрасно делится.

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

Кё>>2. У каждого свои цели. Единая цель у нескольких человек — иллюзия. Типа профессионального роста разработчика.
P>Ерунда, простите. Цель выпустить ближайший релиз едина для всей комманды. И многие другие едины. Есть у каждого и свои собственные никем не разделенные, несомненно. А профессиональный рост разработчика — это не иллюзия. Ну вернее у кого как.

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

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

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

Еще варианты? Как ни крути, но сделан проект будет только если делающий — ОДИН, и никто ему не мешает.

Кё>>3. Sapienti sat.

Умному достаточно Философская часть не удалась, ну и ладно. Если думать долго и упорно, то придешь к тому, что ответственность — это договор с самим собой.

Здравствуйте, Кодёнок, Вы писали:

Так все таки в проекте с домиком, где отвестсвенный один, у него ответственность перед кем? Перед самим собой? И это заказчик назначил его ответственным перед самим собой? А мог бы назначить двоих, и тогда бы каждый отвечал перед собой, или перед обоими? Или ответственнен он все таки перед заказчиком?

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

Здравствуйте, peoplewarrior, Вы писали:

P>Так все таки в проекте с домиком, где отвестсвенный один, у него ответственность перед кем? Перед самим собой? И это заказчик назначил его ответственным перед самим собой? А мог бы назначить двоих, и тогда бы каждый отвечал перед собой, или перед обоими? Или ответственнен он все таки перед заказчиком?

Ни перед кем. Есть договор, между такими-то и такими-то. А есть ответственность, как отношение к своим обязанностям по договору. Если она есть, то исполнение гарантировано, помешать может только форс-мажор.

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

P>До сих пор не понимаю с чем в этом утверждении можно спорить.

Если тебе просто надо чтобы с тобой не спорили, то это запросто.

Здравствуйте, peoplewarrior, Вы писали:

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

P>А что делает менеджер? Мне пока пришло на ум следующее. Менеджер делает:
P>Задачи для девелоперов.
P>Отчеты за комманду.
P>Собрания, где обсуждаются рабочие вопросы.
P>Табличку учета времени, работы, задач.
P>Коммандный дух.(это если он хороший менеджер)
P>Квалификацию и мотивацию сотрудников(не всегда)

P>Что ещё? И какие из этих вещей по вашему мнению главные?

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

Здравствуйте, Кодёнок, Вы писали:

Кё>Если тебе просто надо чтобы с тобой не спорили, то это запросто.

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

Здравствуйте, peoplewarrior, Вы писали:

P>Здравствуйте, Кодёнок, Вы писали:

P>Так все таки в проекте с домиком, где отвестсвенный один, у него ответственность перед кем? Перед самим собой? И это заказчик назначил его ответственным перед самим собой? А мог бы назначить двоих, и тогда бы каждый отвечал перед собой, или перед обоими? Или ответственнен он все таки перед заказчиком?

P>То, что лучшая модель работы — эта такая, при которой ответственность не делится я не спорю. Однако в реальности она практически всегда делится, за какие то вещи себя считают ответственными несколько людей, за другие никого, и сделать так чтобы она не делилась — это серьезная забота руководства начиная с самого верху.
P>До сих пор не понимаю с чем в этом утверждении можно спорить.

В английском языке есть такое слово — derive. Если его переводить как делить со смыслом выводить, порождать, и т.п., тогда можно говорить, что ответственность делится .

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

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

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

G>Другими словами, менеджеры занимаются политикой. А это уже, господа разработчики, такой скотский труд, за который менеджеров можно пожалеть.
Точно, точно... Сам недавно столкнулся с этим, когда начал заниматься больше менеджментом, нежели программингом.

Здравствуйте, Аноним, Вы писали:

А>В английском языке есть такое слово — derive. Если его переводить как делить со смыслом выводить, порождать, и т.п., тогда можно говорить, что ответственность делится .

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

Не всегда можно назначить одного ответственного, и не всегда это делают даже когда можно.

Здравствуйте, peoplewarrior, Вы писали:

P>Не всегда можно назначить одного ответственного

Всегда можно.

Здравствуйте, Кодёнок, Вы писали:
P>>Не всегда можно назначить одного ответственного

Кё>Всегда можно.

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

Здравствуйте, peoplewarrior, Вы писали:

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

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

P>Не всегда можно назначить одного ответственного, и не всегда это делают даже когда можно.

Здравствуйте, peoplewarrior, Вы писали:

P>Не всегда можно назначить одного ответственного, и не всегда это делают даже когда можно.

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

Здравствуйте, Аноним, Вы писали:

А>Мне кажется, что в случае, когда "например ответственность за распределение задач разработчикам делится между менеджером и тех лидом...", ответственность в реальности не делится, а множится на 0 потому что в этом случае уже ни менеджер, ни тех. лид точно не знает, за что же он отвечает. В итоге кто-то из них не делает свою работу с ожидаемым качеством, поскольку считает, что эту работу сделает другой. Последствия, наверное, всем известны .

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

Здравствуйте, Аноним, Вы писали:

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



Не стоит видеть злой умысел в том, что можно объяснить обычной глупостью.