Я практически всю жизнь продавал только то, что уже сделано по собственным идеям, на заказ лишь слегка допиливал. Соответственно, мог лишь очень приблизительно представить, сколько времени потребуется на реализацию той или иной идеи с нуля до полного завершения. С прошлого года пришлось начать брать заказы, и каждый раз чертовски некомфортно оценивать возможные затраты. Даже когда нужно сделать что-то в уже знакомой области, по ходу процесса нередко вылезают сложности, которые решаются только эвристически. Когда область почти незнакомая — неизвестно, сколько времени потребуется на вхождение и борьбу с неизбежными граблями, на которые еще не наступал. Еще нужно как-то учесть периодическую апатию, когда голова категорически отказывается рожать более-менее связный план будущей программы, и приходится кропать что-нибудь второстепенное в надежде, что оно туда уложится.
Когда-то писал на заказ статьи, в том числе и на заданную тему, о которой к моменту заказа практически ничего не знал. Начинал с разных сторон, параллельно осваивая тему, проясняя непонятки, развивая и причесывая описание. Но там проще — в статье достаточно отразить тему в целом, описав ее хорошим языком, и читатели примут. А плохо продуманная программа чревата тормозами, дедлоками, спонтанными непонятными глюками и т.п., которые очень трудно вылавливать.
Как вы оцениваете затраты времени/нервов на разработку в той сфере, где еще не набили руку? Какие резервы закладываете, чтобы не попадать в цейтнот?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Как вы оцениваете затраты времени/нервов на разработку в той сфере, где еще не набили руку? Какие резервы закладываете, чтобы не попадать в цейтнот?
Мне советовали в своё подходить к вопросу наиболее пессимистично а потом результат умножать на π )))
Но лично я в незнакомой области сначала беру время на изучение и оценку затрат времени. Ну то есть на изучение в объёме, достаточном чтобы прикинуть сколько времени уйдёт потом на код.
Matrix has you...
Re[2]: Как вы оцениваете затраты времени на разработку?
У меня подход всегда один — беру времени как можно больше. Многие "эффективные менеджеры" начинают мне рассказывать сказки, мол, почему ты этот проект начал за месяц до выпуска в прод, а не за 3 дня? На что я их посылаю на йух и говорю что сам разбирусь со своими проектами и командой.
Коплю на ланцер
Re: Как вы оцениваете затраты времени на разработку?
ЕМ> чертовски некомфортно оценивать возможные затраты. Даже когда нужно сделать что-то в уже знакомой области, по ходу процесса нередко вылезают сложности, которые решаются только эвристически. Когда область почти незнакомая — неизвестно, сколько времени потребуется на вхождение и борьбу с неизбежными граблями, на которые еще не наступал.
Просто не нужно браться за такие проекты. Нет компетенций и досвидания.
Компетенции, конечно, нужно наращивать (за счёт планового бюджетирования).
Re[3]: Как вы оцениваете затраты времени на разработку?
Здравствуйте, LS9, Вы писали:
LS9>У меня подход всегда один — беру времени как можно больше. Многие "эффективные менеджеры" начинают мне рассказывать сказки, мол, почему ты этот проект начал за месяц до выпуска в прод, а не за 3 дня? На что я их посылаю на йух и говорю что сам разбирусь со своими проектами и командой.
Когда есть команда, за месяц можно много раз перераспределить нагрузки, организовать мозговой штурм и т.п. Когда работаешь в одиночку, все это недоступно. А бесконечного срока тоже не запланируешь.
Re[2]: Как вы оцениваете затраты времени на разработку?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Просто не нужно браться за такие проекты. Нет компетенций и досвидания.
За какие "такие"? Я ж не говорю о переквалификации, например, с экономического софта на программирование DSP. Области безусловно близкие, но знакомые лишь в общих чертах, без понятия о том, какие подводные камни там могут быть. За такие тоже не браться?
ЭФ>Компетенции, конечно, нужно наращивать (за счёт планового бюджетирования).
Это можно делать, когда примерно понятно, какие именно задачи могут возникнуть в ближайшем будущем. Наращивать повсюду — слишком расточительно.
Re[3]: Как вы оцениваете затраты времени на разработку?
Здравствуйте, Sheridan, Вы писали:
S>Мне советовали в своё подходить к вопросу наиболее пессимистично а потом результат умножать на π )))
Почему на π, а не на e? "k будет маловато, возьмем n"?
S>Но лично я в незнакомой области сначала беру время на изучение и оценку затрат времени. Ну то есть на изучение в объёме, достаточном чтобы прикинуть сколько времени уйдёт потом на код.
Это само собой. Я прежде всего о том, когда уже примерно понятно, как делать, но неизвестны подводные грабли, на которые придется наступить в процессе разработки и отладки.
Тут, наверное, нужно пояснить. Я в основном занимаюсь "пассивным" софтом, который встраивается в уже существующую среду (драйвер ядра, драйвер пользовательской подсистемы, фильтр DirectShow и т.п.), и отвечает на вызовы/события этой среды. При этом, с одной стороны, необходимо соблюдать все внутренние правила и соглашения среды, а с другой — независимо протестировать модуль можно только воспроизведением изрядной части окружения (того же ядра), что весьма проблематично. И регулярно возникает ситуация, когда модуль, ведущий себя по всем правилам, порождает глюки. При углубленном исследовании выясняется, что какие-то особенности среды не документированы, какие-то правила нарушаются ею самой, но большинство существующих модулей сделано по типовому шаблону, на котором это не сказывается, поэтому сравнить особо не с чем. И вот эти исследования и съедают львиную долю времени, отведенного на разработку. Как их предсказать — .
Re: Как вы оцениваете затраты времени на разработку?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Как вы оцениваете затраты времени/нервов на разработку в той сфере, где еще не набили руку? Какие резервы закладываете, чтобы не попадать в цейтнот?
Составляю очень, максимально подробный план работ, куда включаю время на изучение неизвестных мне областей и умножаю на... На какое-то число. Не обязательно на Pi, можно и на E.
Re[4]: Как вы оцениваете затраты времени на разработку?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>У тебя только что были "близкие области", откуда "повсюду"?
Так для охвата всех близких областей, где внезапно могут понадобиться знания и опыт, тоже нужно слишком много ресурсов.
ЭФ>Работай организованным тобой коллективом.
Душа не лежит. Никогда не любил руководить людьми, хотя в бытность работы по найму меня регулярно пытались приспособить к руководству. Люди еще менее предсказуемы, чем среды, в которые приходится встраивать софт.
Здравствуйте, CEMb, Вы писали:
CEM>У меня есть задачи в проектах на срок после 2100-го года(почти шутка). CEM>А свой последний проект я оценил в 12 лет, и полгода его уже делаю, норм.
Так это чисто собственные проекты, по ним нет необходимости оценивать время. Я здесь говорю только о проектах, по которым есть обязательства перед кем-либо, кроме себя самого.
Re: Как вы оцениваете затраты времени на разработку?
ЕМ>Когда область почти незнакомая — неизвестно, сколько времени потребуется на вхождение и борьбу с неизбежными граблями, на которые еще не наступал.
Когда область незнакомая, у тебя же есть план действий на такой случай? Как ты обычно действуешь? Тебе нужны поэтапные оценки для твоего плана действий.
Примерно, как я делаю:
1. Оцениваю, сколько мне надо времени, чтобы почитать про новую область/технологию. Даю эту оценку заказчикам, с оговоркой, что после этого я сделаю новую оценку.
2. Оцениваю, сколько уйдёт на разобраться в вопросе. Даю опять эту оценку заказчикам.
3. Даю оценку, сколько времени уйдёт на работу.
Глупо давать оценку сразу на все три пункта, когда первые ещё не пройдены.
И не надо бояться говорить "я не знаю", потому что это правда, и потому что это нормально, но надо при этом уметь объяснить, что потребуется для решения задачи. Хуже всего выглядит человек, который "всё умеет и всегда может дать оценки", а потом бегает, как ужаленный, работает по ночам, и так далее… Люди (заказчики) очень сильно любят определённость, но лучше контролируемая неопределённость в начале проекта, чем бесконтрольная неопределённость в конце, когда ты уверенно назвал сроки, а потом "что-то пошло не так", и график времени начал хаотично скакать... Именно поэтому есть п. 1 и п. 2, которые позволяют поэтапно прийти к правильным оценкам, и даже не надо говорить "я не знаю", чтобы люди не пугались.
Здравствуйте, Евгений Музыченко, Вы писали:
CEM>>У меня есть задачи в проектах на срок после 2100-го года(почти шутка). CEM>>А свой последний проект я оценил в 12 лет, и полгода его уже делаю, норм.
ЕМ>Так это чисто собственные проекты, по ним нет необходимости оценивать время. Я здесь говорю только о проектах, по которым есть обязательства перед кем-либо, кроме себя самого.
Это мои рабочие проекты на теперешней работе.
Здравствуйте, CEMb, Вы писали:
CEM>1. Оцениваю, сколько мне надо времени, чтобы почитать про новую область/технологию. Даю эту оценку заказчикам, с оговоркой, что после этого я сделаю новую оценку. CEM>2. Оцениваю, сколько уйдёт на разобраться в вопросе. Даю опять эту оценку заказчикам. CEM>3. Даю оценку, сколько времени уйдёт на работу.
У меня основные внеплановые затраты и времени, и нервов возникают ближе к завершению разработки, когда всплывают какие-нибудь нюансы, которых на начальных этапах просто не было оснований предполагать.
CEM>Люди (заказчики) очень сильно любят определённость, но лучше контролируемая неопределённость в начале проекта
В том и вопрос, насколько она контролируемая. Я им честно говорю, что могут возникать непредвиденные сложности из-за недостатков документации, внутренних ошибок среды и т.п. Но завышение сроков/цен вдвое-втрое на основе одних только предположений выглядит абсурдно.
Примерная аналогия, чтоб было понятно — разработка сайта под популярные браузеры. Заказчик хочет определенный вид и поведение, они вроде бы неплохо укладываются в существующие стандарты. Когда сделана бОльшая часть кода, выясняется, что какой-нибудь популярный браузер некорректно обрабатывает именно тот частный случай, на который завязана изрядная часть функциональности. Багрепорты разработчикам либо игнорируются, либо сопровождаются обещаниями "исправить когда-нибудь", поскольку жалуются на это нечасто. Переделывать долго и чревато теми же проблемами с тем же или другим браузером. Как в таких случаях обычно поступают?
Re[3]: Как вы оцениваете затраты времени на разработку?
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Мне советовали в своё подходить к вопросу наиболее пессимистично а потом результат умножать на π ))) ЕМ>Почему на π, а не на e? "k будет маловато, возьмем n"?
Именно
ЕМ> И регулярно возникает ситуация, когда модуль, ведущий себя по всем правилам, порождает глюки. При углубленном исследовании выясняется, что какие-то особенности среды не документированы, какие-то правила нарушаются ею самой, но большинство существующих модулей сделано по типовому шаблону, на котором это не сказывается, поэтому сравнить особо не с чем. И вот эти исследования и съедают львиную долю времени, отведенного на разработку. Как их предсказать — .
Никак. Для этого π и используется...
Здравствуйте, Евгений Музыченко, Вы писали:
CEM>>Это мои рабочие проекты на теперешней работе.
ЕМ>Перед кем именно у Вас есть обязательство сделать проект в течение 12 лет?
Перед начальством и конторой. Там, на самом деле, несколько проектов, суммарный расчёт времени был 12-13 лет.
Re[3]: Как вы оцениваете затраты времени на разработку?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У меня основные внеплановые затраты и времени, и нервов возникают ближе к завершению разработки, когда всплывают какие-нибудь нюансы, которых на начальных этапах просто не было оснований предполагать.
Вот поэтому нужно уделять должное внимание 1-2 пунктам. Смешно, но "чем меньше сделаешь, тем меньше потом переделывать" — как раз тут и работает.
ЕМ>В том и вопрос, насколько она контролируемая. Я им честно говорю, что могут возникать непредвиденные сложности из-за недостатков документации, внутренних ошибок среды и т.п. Но завышение сроков/цен вдвое-втрое на основе одних только предположений выглядит абсурдно.
Опять же, 1-2 пункты, чем больше времени потрачено на разбор матчасти, тем меньше непредвиденных сложностей.
ЕМ>Примерная аналогия, чтоб было понятно — разработка сайта под популярные браузеры. Заказчик хочет определенный вид и поведение, они вроде бы неплохо укладываются в существующие стандарты. Когда сделана бОльшая часть кода, выясняется, что какой-нибудь популярный браузер некорректно обрабатывает именно тот частный случай, на который завязана изрядная часть функциональности. Багрепорты разработчикам либо игнорируются, либо сопровождаются обещаниями "исправить когда-нибудь", поскольку жалуются на это нечасто. Переделывать долго и чревато теми же проблемами с тем же или другим браузером. Как в таких случаях обычно поступают?
Я поступаю честно, иду и говорю заказчику: у нас такая-то проблема с таким-то браузером, у нас n вариантов решений, каждый со своими плюсами/минусами и своим сроком. Дальше мы вместе решаем, что с этим делать.
Re[4]: Как вы оцениваете затраты времени на разработку?
Здравствуйте, CEMb, Вы писали:
CEM>Вот поэтому нужно уделять должное внимание 1-2 пунктам. Смешно, но "чем меньше сделаешь, тем меньше потом переделывать" — как раз тут и работает.
Это хорошо работает в отношении типовых вопросов вроде использования структурного программирования или инкапсуляции, по которым уже наработаны типовые же решения. На этом уровне у меня почти никогда не возникало проблем. А вот когда уже после выбора схемы взаимодействия моего модуля с его окружением выясняется, что окружение на определенных путях держит внутри себя какую-нибудь недокументированную блокировку, отчего возникают дедлоки, бывало не раз. Иногда приходилось выворачивать схему взаимодействия наизнанку, а предсказать это заранее не было разумной возможности.
CEM>Я поступаю честно, иду и говорю заказчику: у нас такая-то проблема с таким-то браузером, у нас n вариантов решений, каждый со своими плюсами/минусами и своим сроком. Дальше мы вместе решаем, что с этим делать.
У меня в итоге так и получается. Думал, сообщество уже наработало какие-то другие шаблоны на этот счет.
Начинал с разных сторон, параллельно осваивая тему, проясняя непонятки, развивая и причесывая описание. Но там проще — в статье достаточно отразить тему в целом, описав ее хорошим языком, и читатели примут. А плохо продуманная программа чревата тормозами, дедлоками, спонтанными непонятными глюками и т.п., которые очень трудно вылавливать.
.
