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

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

Примерно, как я делаю:

1. Оцениваю, сколько мне надо времени, чтобы почитать про новую область/технологию. Даю эту оценку заказчикам, с оговоркой, что после этого я сделаю новую оценку.
2. Оцениваю, сколько уйдёт на разобраться в вопросе. Даю опять эту оценку заказчикам.
3. Даю оценку, сколько времени уйдёт на работу.

Глупо давать оценку сразу на все три пункта, когда первые ещё не пройдены.

И не надо бояться говорить "я не знаю", потому что это правда, и потому что это нормально, но надо при этом уметь объяснить, что потребуется для решения задачи. Хуже всего выглядит человек, который "всё умеет и всегда может дать оценки", а потом бегает, как ужаленный, работает по ночам, и так далее… Люди (заказчики) очень сильно любят определённость, но лучше контролируемая неопределённость в начале проекта, чем бесконтрольная неопределённость в конце, когда ты уверенно назвал сроки, а потом "что-то пошло не так", и график времени начал хаотично скакать... Именно поэтому есть п. 1 и п. 2, которые позволяют поэтапно прийти к правильным оценкам, и даже не надо говорить "я не знаю", чтобы люди не пугались.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Как вы оцениваете затраты времени/нервов на разработку в той сфере, где еще не набили руку? Какие резервы закладываете, чтобы не попадать в цейтнот?

1. Разбиваешь задачу на подзадачи трудоемкостью не более 4-х часов.

Очень удобно в виде mind map или дерева. Дробишь ветки на листья до тех пор, пока не останется веток и все листья будут < 4 часа.

Почему 4? Потому что за день надо сделать два. А учитывая, что надо еще время на чай/туалет, остаются какие-то часа 3 — это вполне конкретный срок, который можно предсказать относительно точно.

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


2. Полученную трудоемкость умножаешь на 2.

Почему 2? Потому что ты выписал только видимую часть задач. В следующих проектах коэффициент можно скорректировать.


Дополнительная прелесть метода в том, что он позволяет точно отслеживать прогресс по задаче. То есть если например выполнено 50% видимой трудоемкости, то вполне можно предположить, что до конца проекта примерно столько же времени, сколько уже потрачено.

Здравствуйте, Евгений Музыченко, Вы писали:

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

Вот поэтому нужно уделять должное внимание 1-2 пунктам. Смешно, но "чем меньше сделаешь, тем меньше потом переделывать" — как раз тут и работает.

ЕМ>В том и вопрос, насколько она контролируемая. Я им честно говорю, что могут возникать непредвиденные сложности из-за недостатков документации, внутренних ошибок среды и т.п. Но завышение сроков/цен вдвое-втрое на основе одних только предположений выглядит абсурдно.

Опять же, 1-2 пункты, чем больше времени потрачено на разбор матчасти, тем меньше непредвиденных сложностей.

ЕМ>Примерная аналогия, чтоб было понятно — разработка сайта под популярные браузеры. Заказчик хочет определенный вид и поведение, они вроде бы неплохо укладываются в существующие стандарты. Когда сделана бОльшая часть кода, выясняется, что какой-нибудь популярный браузер некорректно обрабатывает именно тот частный случай, на который завязана изрядная часть функциональности. Багрепорты разработчикам либо игнорируются, либо сопровождаются обещаниями "исправить когда-нибудь", поскольку жалуются на это нечасто. Переделывать долго и чревато теми же проблемами с тем же или другим браузером. Как в таких случаях обычно поступают?

Я поступаю честно, иду и говорю заказчику: у нас такая-то проблема с таким-то браузером, у нас n вариантов решений, каждый со своими плюсами/минусами и своим сроком. Дальше мы вместе решаем, что с этим делать.

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

TMU>Можно хотя бы намекнуть, что за проекты с таким сроком реализации? Ведь через 10 лет будет одно сплошное телевидение весь технологический стек может поменяться?

Не знаю, что у автора, но длинные проекты вполне встречаются, если это полный жизненный цикл изделия: исследования, прототипы, разработка, сертификация, выход на рынок, поддержка и доработка. Жизненный цикл какой-нибудь PS 3 явно больше 10 лет. Если же это медицинские или военные продукты, то ещё дольше.
Потом, крупные информационные системы масштаба города или региона/страны. Помню эпический переход ставропольского пенсионного фонда на db2 (или с него?) — товариц рассказывал. Это именно что планы на годы и годы вперёд.

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

B>1. Разбиваешь задачу на подзадачи трудоемкостью не более 4-х часов.

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

B>Если что-то вообще не знаешь, сколько займет, гуглишь и разбираешься. Весь процесс может занять несколько дней.

Разобраться — это полдела. Основные проблемы возникают на этапе стыковки своих модулей с подсистемой ОС, для которой они делаются, а там процесс бывает непредсказуем.

Например, осенью я делал фильтр DirectShow для устройств ASIO. Ни с тем, ни с другим раньше плотно не работал, только очень поверхностно. Но для ASIO-драйвера мой фильтр — это клиент, все управление идет от него, поэтому никаких особых проблем не возникло, только мелкие. А для графа DirectShow фильтр — это сервер, управление идет от графа. Документация у MS довольно убога, рассчитана на использование готового фреймворка Base Classes, на котором делает фильтры подавляющее большинство разработчиков. Я пару раз пользовался подобными фреймворками, но каждый раз имел от них проблемы в неочевидных случаях, и пришел к выводу, что проще было бы все сделать с нуля. В этот раз сделал с нуля, но поимел проблемы в других неочевидных случаях, когда из документации не было понятно, какие интерфейсы фильтр поддерживать обязан, а какие — нет. В итоге несколько реализованных интерфейсов так и не пригодились, поскольку причины проблем были в других местах.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Как вы оцениваете затраты времени/нервов на разработку в той сфере, где еще не набили руку? Какие резервы закладываете, чтобы не попадать в цейтнот?
Мне советовали в своё подходить к вопросу наиболее пессимистично а потом результат умножать на π )))
Но лично я в незнакомой области сначала беру время на изучение и оценку затрат времени. Ну то есть на изучение в объёме, достаточном чтобы прикинуть сколько времени уйдёт потом на код.

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

LS9>У меня подход всегда один — беру времени как можно больше. Многие "эффективные менеджеры" начинают мне рассказывать сказки, мол, почему ты этот проект начал за месяц до выпуска в прод, а не за 3 дня? На что я их посылаю на йух и говорю что сам разбирусь со своими проектами и командой.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Как вы оцениваете затраты времени/нервов на разработку в той сфере, где еще не набили руку? Какие резервы закладываете, чтобы не попадать в цейтнот?

Составляю очень, максимально подробный план работ, куда включаю время на изучение неизвестных мне областей и умножаю на... На какое-то число. Не обязательно на Pi, можно и на E.

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

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

Как вы оцениваете затраты времени/нервов на разработку в той сфере, где еще не набили руку? Какие резервы закладываете, чтобы не попадать в цейтнот?

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

ЕМ> чертовски некомфортно оценивать возможные затраты. Даже когда нужно сделать что-то в уже знакомой области, по ходу процесса нередко вылезают сложности, которые решаются только эвристически. Когда область почти незнакомая — неизвестно, сколько времени потребуется на вхождение и борьбу с неизбежными граблями, на которые еще не наступал.

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

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

ЭФ>Просто не нужно браться за такие проекты. Нет компетенций и досвидания.

За какие "такие"? Я ж не говорю о переквалификации, например, с экономического софта на программирование DSP. Области безусловно близкие, но знакомые лишь в общих чертах, без понятия о том, какие подводные камни там могут быть. За такие тоже не браться?

ЭФ>Компетенции, конечно, нужно наращивать (за счёт планового бюджетирования).

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

ЕМ> За такие тоже не браться?

А что смешного-то? Да, не браться.

ЕМ> Наращивать повсюду — слишком расточительно.

У тебя только что были "близкие области", откуда "повсюду"?

ЕМ> Когда работаешь в одиночку

Если это проблема, прекращай эту порочную практику.
Работай организованным тобой коллективом.

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

S>Мне советовали в своё подходить к вопросу наиболее пессимистично а потом результат умножать на π )))

Почему на π, а не на e? "k будет маловато, возьмем n"?

S>Но лично я в незнакомой области сначала беру время на изучение и оценку затрат времени. Ну то есть на изучение в объёме, достаточном чтобы прикинуть сколько времени уйдёт потом на код.

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

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

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

ЭФ>У тебя только что были "близкие области", откуда "повсюду"?

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

ЭФ>Работай организованным тобой коллективом.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А бесконечного срока тоже не запланируешь.

У меня есть задачи в проектах на срок после 2100-го года(почти шутка).
А свой последний проект я оценил в 12 лет, и полгода его уже делаю, норм.

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

CEM>У меня есть задачи в проектах на срок после 2100-го года(почти шутка).
CEM>А свой последний проект я оценил в 12 лет, и полгода его уже делаю, норм.

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

Здравствуйте, Евгений Музыченко, Вы писали:

CEM>>У меня есть задачи в проектах на срок после 2100-го года(почти шутка).
CEM>>А свой последний проект я оценил в 12 лет, и полгода его уже делаю, норм.

ЕМ>Так это чисто собственные проекты, по ним нет необходимости оценивать время. Я здесь говорю только о проектах, по которым есть обязательства перед кем-либо, кроме себя самого.
Это мои рабочие проекты на теперешней работе.

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

CEM>Это мои рабочие проекты на теперешней работе.

Перед кем именно у Вас есть обязательство сделать проект в течение 12 лет?

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

CEM>1. Оцениваю, сколько мне надо времени, чтобы почитать про новую область/технологию. Даю эту оценку заказчикам, с оговоркой, что после этого я сделаю новую оценку.
CEM>2. Оцениваю, сколько уйдёт на разобраться в вопросе. Даю опять эту оценку заказчикам.
CEM>3. Даю оценку, сколько времени уйдёт на работу.

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

CEM>Люди (заказчики) очень сильно любят определённость, но лучше контролируемая неопределённость в начале проекта

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

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

Здравствуйте, Евгений Музыченко, Вы писали:

S>>Мне советовали в своё подходить к вопросу наиболее пессимистично а потом результат умножать на π )))
ЕМ>Почему на π, а не на e? "k будет маловато, возьмем n"?
Именно

ЕМ> И регулярно возникает ситуация, когда модуль, ведущий себя по всем правилам, порождает глюки. При углубленном исследовании выясняется, что какие-то особенности среды не документированы, какие-то правила нарушаются ею самой, но большинство существующих модулей сделано по типовому шаблону, на котором это не сказывается, поэтому сравнить особо не с чем. И вот эти исследования и съедают львиную долю времени, отведенного на разработку. Как их предсказать — .
Никак. Для этого π и используется...

Здравствуйте, Евгений Музыченко, Вы писали:

CEM>>Это мои рабочие проекты на теперешней работе.

ЕМ>Перед кем именно у Вас есть обязательство сделать проект в течение 12 лет?

Перед начальством и конторой. Там, на самом деле, несколько проектов, суммарный расчёт времени был 12-13 лет.

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

CEM>Вот поэтому нужно уделять должное внимание 1-2 пунктам. Смешно, но "чем меньше сделаешь, тем меньше потом переделывать" — как раз тут и работает.

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

CEM>Я поступаю честно, иду и говорю заказчику: у нас такая-то проблема с таким-то браузером, у нас n вариантов решений, каждый со своими плюсами/минусами и своим сроком. Дальше мы вместе решаем, что с этим делать.

У меня в итоге так и получается. Думал, сообщество уже наработало какие-то другие шаблоны на этот счет.

ЕМ>>Перед кем именно у Вас есть обязательство сделать проект в течение 12 лет?
CEM>Перед начальством и конторой. Там, на самом деле, несколько проектов, суммарный расчёт времени был 12-13 лет.



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

Разбиваю задачу на подзадачи, оцениваю всё по отдельности (с округлением вверх, обычно у меня единица оценки это полдня). Сумму умножаю на 4, это примерная оценка. Если чувствую себя не очень (вариант про апатию), то умножаю на 8, хотя предпочитаю в таких случаях отказаться от задачи.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Как вы оцениваете затраты времени/нервов на разработку в той сфере, где еще не набили руку? Какие резервы закладываете, чтобы не попадать в цейтнот?
Ответ зависит от того, кому нужна оценка.
Оценка нужна:
1. Менеджеру проекта?
2. Оценка нужна заказчику?
3. Оценка нужна инвесторам?

1. Честно говоришь, что нет опыта, нужно N дней на прототипирование, после чего ты сможешь дать оценку с рисками.
2. Я бы не обманывал заказчика и не связывался бы с тем, в чем кроме теоретических знаний, ни чего нет.
Почему? Ну потому что заказчику нужно быстро, и он не готов оплачивать твое обучение.
Конечно же, если ты мастер в React или Angular, а заказчик хочет Vue, ну тут ни чего страшного нет, можно заложить 2-3 дня на прокачку Vue.
Но если ты ни когда не работал с ML или DSP, то браться за работу скорее всего не надо, будешь работать себе в убыток и карму попортишь.
3. Тут все проще, зависит от того сколько денег есть у инвесторов. Но опять же, что бы инвесторы были готовы отдать тебе свои деньги, нужен какой-то работающий прототип, соответственно ты уже не нуб

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


TMU>Можно хотя бы намекнуть, что за проекты с таким сроком реализации? Ведь через 10 лет будет одно сплошное телевидение весь технологический стек может поменяться?

Я бы, конечно, хотел бы это всё написать за 1-2 года.
У нас был большой пакет программ, написанный за лет двадцать или больше. На старых языках и на старых технологиях. С приходом новых операционок старые технологии начали отваливаться. Можно было бы менять старые технологии на новые в старых проектах, но мне было крайне неохота работать на старых языках, в старых IDE (там даже прокрутка колесом не работает, приходилось тыкать мышкой в скроллбар, Карл!), которые уже лет 10 не поддерживаются. Кроме того, рано или поздно этот код просто перестанет работать под новыми операционками, и нам, таки, придётся что-то с этим делать, и лучше начать делать заранее — вот с такими мощными аргументами я всех убедил, что надо бросать всё старое и зажигать всё новое. Саму систему, для которой этот пакет программ используется, хотят отправить на покой, но она лет пять ещё проработает точно, и людям, которые с ней работают, нужны инструменты, поэтому есть смысл делать это. Ну и вообще, мне это делать интересно

На счёт стека технологий — да, всё верно, на самом деле я постоянно в сомнениях, что выбрал всё верно. За часть я спокоен, а вот на счёт использования родного Windows UI — не очень. Но тут дело было ровно как у топик-стартера: если за родное UI я был уверен, что на нём можно сделать абсолютно всё и быстро, то если бы я взял за основу что-то иное, я не смог бы утверждать, что смогу сделать на нём всё, что потребуется. Т.е. тогда бы мне пришлось плотно разбираться с другими UI, получать хороший практический опыт, а на это надо время, которого и так мало

Здравствуйте, Евгений Музыченко, Вы писали:

CEM>>Я поступаю честно, иду и говорю заказчику: у нас такая-то проблема с таким-то браузером, у нас n вариантов решений, каждый со своими плюсами/минусами и своим сроком. Дальше мы вместе решаем, что с этим делать.

ЕМ>У меня в итоге так и получается. Думал, сообщество уже наработало какие-то другие шаблоны на этот счет.

Мне думается, это извечная проблема Да, в общем-то, такое её решение довольно нормальное, так что и не проблема вовсе
Нельзя предусмотреть всё, и все нормальные люди это понимают.

Здравствуйте, Евгений Музыченко, Вы писали:


Нужно мысленно представить процесс, умножить на 2 и прибавить 20% на непредвиденные трудности.

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

_>1. Честно говоришь, что нет опыта, нужно N дней на прототипирование, после чего ты сможешь дать оценку с рисками.
_>2. Я бы не обманывал заказчика и не связывался бы с тем, в чем кроме теоретических знаний, ни чего нет.
_>Почему? Ну потому что заказчику нужно быстро, и он не готов оплачивать твое обучение.
_>Конечно же, если ты мастер в React или Angular, а заказчик хочет Vue, ну тут ни чего страшного нет, можно заложить 2-3 дня на прокачку Vue.
_>Но если ты ни когда не работал с ML или DSP, то браться за работу скорее всего не надо, будешь работать себе в убыток и карму попортишь.

Херня, всю жизнь меняю область деятельности, просто одна тема надоедает через какое то время. Никогда проблем не было. Причем не важно, это на обычном компе или на микроконтроллере. И даже в новых для себя областях никогда не задерживался более 6 мес в кодерах. Главное условие — тема должна меня интересовать сама по себе, а не деньгами.