Как бы ни глупо звучало

Сейчас везде можно agile, итерации и тп. Но вроде как такой процесс хорошо ложится на работы, где задачи короткие (либо задача более-менее ясна и ее можно хорошо поделить на куски) и где процент задач, в которых неожиданно обнаруживаются долго\трудно\не-разрешимые проблемы, сравнительно мал.
А как быть если у вас почти вся работа что-то напоминающее R&D? Как бы любая ваша задача получается совершенно новой, непредсказуемой и не видно неделю ее делать или год?
Получается абстрактно, тк реальные задачи трудно объяснять. Ну, скажем, необходимо реализовать некий компонент, в основном состоящий из сложных геометрических операций. И затем его вставить в существующий (уже второй десяток лет) говнокодкодебейз. Вы никогда не сталкивались с такими операциями и кодом, найти доп. информацию тоже по сути неоткуда. Вы можете провести инвестигейт и разбить это все на какие-то очень крупные куски, но понять сколько времени уйдет на кусок — это практически угадайка, тк вы не знаете толком с чем столкнетесь. Делить эти куски дальше тоже не очень получается, тк не дойдя до него (а зачастую и дойдя) видно только крайне примерно что там делать. А детали всплывают уже в процессе. Далее, допустим, вы всетаки "это" реализовали. Так вам еще приходится (или придется) бороться со старым кодом, куда вы это пытаетесь воткнуть. Опять же, из-за размера и сложности совершенно неясно что ты можешь зацепить и насколько долго могут растянуться правки.

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

Задач (1) и (2) половина или больше. Итого:
1) крайне сложно строить хотябы какие-то планы. Часто получается "все идет как идет, куда придет туда придет".
2) на итерациях размером 6-9 месяцев всетаки попадаю в "план", забирая на задачи время с 3-кратным запасом. Причем иногда приходится какие-то неразрешимые части отбрасывать
3) сложно контролировать кого-то другого, тк также неясно (пока не сядешь делать сам тоже самое) столкнулся ли человек с проблемой, или просто особо не напрягается

Хочу послушать истории менеджеров\техлидов, кто сталкивался с такими вещами — как вы организовывали процесс разработки? Какие цели вы ставили для этого процесса, что получалось и что нет?

Перечитал и понял что русский я забываю

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

M>Как бы ни глупо звучало

Не берись за то чего не знаешь. Сначала обучение..

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

B>Не берись за то чего не знаешь. Сначала обучение..
Это не языки и не фреймворки. Каждая задача по сути единична и существует только для этого проекта. Учиться неукого, информации по таким вещам не существует — решение надо выдумать.

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

M>Как бы ни глупо звучало

M>Сейчас везде можно agile, итерации и тп. Но вроде как такой процесс хорошо ложится на работы, где задачи короткие (либо задача более-менее ясна и ее можно хорошо поделить на куски) и где процент задач, в которых неожиданно обнаруживаются долго\трудно\не-разрешимые проблемы, сравнительно мал.
M>А как быть если у вас почти вся работа что-то напоминающее R&D?

Нечто похожее обсуждали здесь

Автор: Stanislav V. Zudin
Дата: 01.07.13

.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Нечто похожее обсуждали здесь

Автор: Stanislav V. Zudin
Дата: 01.07.13

.
И правда.. Хотя ни к чему особому, как я понял, не пришли.

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

M>Хочу послушать истории менеджеров\техлидов, кто сталкивался с такими вещами — как вы организовывали процесс разработки? Какие цели вы ставили для этого процесса, что получалось и что нет?

Как бы ни глупо звучало, но вопрос серьезный:

Какова цель планирования? Чем не устраивает "все идет как идет, куда придет туда придет"?

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

Что реально изменится в вашей деятельности от того, напишите вы в плане три месяца или шесть?

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

BT>Как бы ни глупо звучало, но вопрос серьезный:
BT>Какова цель планирования? Чем не устраивает "все идет как идет, куда придет туда придет"?
BT>Что реально изменится в вашей деятельности от того, напишите вы в плане три месяца или шесть?

Вопрос и правда серьезный. Я попытаюсь немного погодя на него ответить с моей собственной точки зрения (что бы я хотел), а пока:
1) с меня.. требуют оценки для дедлайнов. якобы мы должны четко оповещать кастомеров о том, что будет сделано в очередном релизе. поэтому планируется круг задач на ~6-9 мес. и если пообещали — их должны сделать. политика какая-то.
2) мне бы как раз и хотелось услышать от людей что и зачем они пытались делать на таких проктах. что получилось, что не получилось, какой опыт вынесли. т.е. я бы тоже с удовольствием про цели послушал
3) этот пункт немного не связан с планированием как таковым, и я не знаю с какой стороны к нему подойти — но крайне сложно контролировать других работников на таких задачах. может он там еле работает, на самом деле, а не проблемы у него. делает только чтобы красочно нарассказать. а может и правда сталкивается со сложнорешаемыми вещами.

M>1) с меня.. требуют оценки для дедлайнов. якобы мы должны четко оповещать кастомеров о том, что будет сделано в очередном релизе. поэтому планируется круг задач на ~6-9 мес. и если пообещали — их должны сделать. политика какая-то.

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

M>2) мне бы как раз и хотелось услышать от людей что и зачем они пытались делать на таких проктах. что получилось, что не получилось, какой опыт вынесли. т.е. я бы тоже с удовольствием про цели послушал

Как обычно. Снача 4-часовой рисеч, корректировка что мы хотим сделать. Затем либо начинаем работать, либо еще 1-2 дня изучаем с чем же таким веселым нам выпало бороться. Опять корректировка. Ну и дальше вперед и с песней. Если после нескольких дней исследований объем работы не выявляется даже приблизительно — руководству так и докладывается. Если они "не могу этого принять по религиозным причинам" — тут уже по ситуации. Лично я стараюсь не работать с сектантами и совсем уж неадекватными людьми — слишком много усилий требуется для компенсации их картины мира, развернутой под непривычным углом. Если нет выбора — то используются фейковые метрики вида "понимаете, та часть программы, которую нам предстоит модифицировать — это миллион строчек кода. Даже если предположить, что изменение затронет 10%, сто тысячь строчек кода — разработчику понадобится несколько дней, чтобы только их бегло просмотреть! А ведь их еще менять надо! Представьте себе сто тысячь строк кода — это две сотни толстых книг! Если я их на пол положу — стопка до потолка будет! А ребята со всем этим работает. Так что оптимистический прогноз месяц. Но если хотите быстрее...". В целом "Для research — Agile в миниатюре, раскручивающиеся итерации для одной задачи".

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

По окончании итераций они докладывают / записывают в confluence результаты. Результаты сравниваются с "средним адекватным результатом" который менеджер либо знает сам, либо выводит с помощью интервьюирования подчиненных. Опять же, хорошо помогает разворачивать подчиненных мониторами к себе — если есть исследовательская деятельность и подозрения, что шибко сильно халявят. Не все на это соглашаются, но я такую возможность обычно оговариваю сразу при приеме на работу. Еще никто по этой причине не отказался.

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

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


M>Вопрос и правда серьезный. Я попытаюсь немного погодя на него ответить с моей собственной точки зрения (что бы я хотел), а пока:
M>1) с меня.. требуют оценки для дедлайнов. якобы мы должны четко оповещать кастомеров о том, что будет сделано в очередном релизе. поэтому планируется круг задач на ~6-9 мес. и если пообещали — их должны сделать. политика какая-то.

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

M>2) мне бы как раз и хотелось услышать от людей что и зачем они пытались делать на таких проктах. что получилось, что не получилось, какой опыт вынесли. т.е. я бы тоже с удовольствием про цели послушал

Целями планов могут быть:
1. Правильное распределение работы. У нас есть команда, есть список фич которые мы бы хотели видеть в релизе и приоритетов. План отвечает на вопросы типа сколько разработчиков на какую фичу надо, кому чего поручить. Естественно, если неправильно оценили — корректируется в процессе.
2. Мотивация сотрудников, чтобы не расслаблялись(об этом ниже)
3. Спокойствие нервов высшего начальства или заказчика. Тут главное сохранить это спокойствие, когда план начнет сильно меняться, причем в стандартную сторону.
4. Имитация деятельности манагера.
5. Оценка того, стоит ли вообще за проект браться.
6. Оценка сколько взять с заказчика при оплате фикс прайс. Но это для ресерч задач нежелательно.

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




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

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

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

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

B>>Не берись за то чего не знаешь. Сначала обучение..
M>Это не языки и не фреймворки. Каждая задача по сути единична и существует только для этого проекта. Учиться неукого, информации по таким вещам не существует — решение надо выдумать.
Слово "Выдумать" подразумевает уже знать как. По английский это привычно звучит. А пока не знаешь как делать, лучше не браться. Или разделить работу на этапы. Первый этап назвать "Проектирование".

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

M>Как бы ни глупо звучало

M>А как быть если у вас почти вся работа что-то напоминающее R&D? Как бы любая ваша задача получается совершенно новой, непредсказуемой и не видно неделю ее делать или год?

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

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

_O_>12 лет работаю с такими задачами. Как-то всегда интуитивно умудрялся оценивать сроки. Ошибки были лишь +1-3 дня. Причем обычно из-за конфликтующих других задач.
Ого. В 3 дня промахнуться всего? В среднем сколько срок решения самой задачи при такой погрешности?

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

И как вы добились таких результатов в предсказании, что и как делаете, что за задачи?

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

M>>Как бы ни глупо звучало

B>Не берись за то чего не знаешь. Сначала обучение..

Любое более менее R&D — это как раз изготовление или узнавание того, чего не знаешь. Если хорошее R&D, то обучиться не у кого, потому что никто не знает, как надо.

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

_O_>12 лет работаю с такими задачами. Как-то всегда интуитивно умудрялся оценивать сроки. Ошибки были лишь +1-3 дня. Причем обычно из-за конфликтующих других задач.

Это при характерном времени в полгода три дня ошибка, или всё-таки характерное время ближе к неделе?

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

M>Хочу послушать истории менеджеров\техлидов, кто сталкивался с такими вещами — как вы организовывали процесс разработки? Какие цели вы ставили для этого процесса, что получалось и что нет?

Тут все просто: не понимаешь, значит не можешь адекватно запланировать. Нужно не пытаться сразу "угадать" конечную цифру, а назначить 1-5 дней на ресерч. Задача рисрча устранить неопределнности. Допустим нам нужно встроить поддержку геометрии в MongoDB, это пример максимально похожий на твой. Какие неопределенности тут могут быть, непонятно как мы будем представлять геометрию пользователю, какие операции над ней нужны, как мы ее будем хранить и т.д. В процессе рисерча мы изучаем существующие решения и понимаем что нам достаточно модели OGC, данные пользователю мы будем представлять в виде GeoJSON, для работы с геометрией используем libgeos, и еще потребуется добавить новый тип индекса для геометрии и научить оптимизатор запросов пользоваться этим индексом. Если до этого мы не копались в MongoDB, мы сделаем прототип чтобы понять как мы это будем делать. Такой рисерч не составляет труда запланировать, особенно если ты постоянно этим занимаешься. После того как большинство неопределенностей устранены несложно запланировать и девелопмент.

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

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

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

M>>>Как бы ни глупо звучало

B>>Не берись за то чего не знаешь. Сначала обучение..

S>Любое более менее R&D — это как раз изготовление или узнавание того, чего не знаешь. Если хорошее R&D, то обучиться не у кого, потому что никто не знает, как надо.
Вот это меня и удивляет. Если есть мысли и понимание что и как делать, тогда и надо делать. А если не знаешь как, то и не берись.

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

B>А пока не знаешь как делать, лучше не браться. Или разделить работу на этапы. Первый этап назвать "Проектирование".

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

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

B>>>Не берись за то чего не знаешь. Сначала обучение..

S>>Любое более менее R&D — это как раз изготовление или узнавание того, чего не знаешь. Если хорошее R&D, то обучиться не у кого, потому что никто не знает, как надо.

B>Вот это меня и удивляет. Если есть мысли и понимание что и как делать, тогда и надо делать. А если не знаешь как, то и не берись.

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

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

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

M>>Хочу послушать истории менеджеров\техлидов, кто сталкивался с такими вещами — как вы организовывали процесс разработки? Какие цели вы ставили для этого процесса, что получалось и что нет?

"Неизвестные задачи" бывают разные.

Задачи типа I: понятно как писать, непонятно принесет ли это результат. Например, требуется написать шахматный движок, который бы играл в силу 2700. Тут, в принципе, понятно что делать: наиболее быстрый перебор, alpha-beta, null move, move killers, Z-Orbice, оценка позиции, ... По каждому пункту я могу более-менее точно сказать, сколько мне надо на реализацию. Но непонятно, получится ли в результате движок, который играет в нужную силу, или этого будет недостаточно. Иногда путей решения может быть несколько, и непонятно, какой из них лучше. Гарантировать результат в этом случае нельзя. Но можно оценить срок выполнения работ. Разработка тут так и велась по принципу: делаю фичу #666, сделаю к четвергу, а что нам это даст — непонятно.

Задачи типа II: понятно, что необходимо реализовать, непонятно как — нет нужного опыта работы с библиотеками. В этом случае если нужны сроки, то необходимо изучать непонятные места, писать доки по архитектуре. Кодирование начинать после подготовки документации.