ЕМ>>Перед кем именно у Вас есть обязательство сделать проект в течение 12 лет? CEM>Перед начальством и конторой. Там, на самом деле, несколько проектов, суммарный расчёт времени был 12-13 лет.
Можно хотя бы намекнуть, что за проекты с таким сроком реализации? Ведь через 10 лет будет одно сплошное телевидение весь технологический стек может поменяться?
Re: Как вы оцениваете затраты времени на разработку?
Разбиваю задачу на подзадачи, оцениваю всё по отдельности (с округлением вверх, обычно у меня единица оценки это полдня). Сумму умножаю на 4, это примерная оценка. Если чувствую себя не очень (вариант про апатию), то умножаю на 8, хотя предпочитаю в таких случаях отказаться от задачи.
Здравствуйте, TMU_1, Вы писали:
TMU>Можно хотя бы намекнуть, что за проекты с таким сроком реализации? Ведь через 10 лет будет одно сплошное телевидение весь технологический стек может поменяться?
Не знаю, что у автора, но длинные проекты вполне встречаются, если это полный жизненный цикл изделия: исследования, прототипы, разработка, сертификация, выход на рынок, поддержка и доработка. Жизненный цикл какой-нибудь PS 3 явно больше 10 лет. Если же это медицинские или военные продукты, то ещё дольше.
Потом, крупные информационные системы масштаба города или региона/страны. Помню эпический переход ставропольского пенсионного фонда на db2 (или с него?) — товариц рассказывал. Это именно что планы на годы и годы вперёд.
Re: Как вы оцениваете затраты времени на разработку?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Как вы оцениваете затраты времени/нервов на разработку в той сфере, где еще не набили руку? Какие резервы закладываете, чтобы не попадать в цейтнот?
Ответ зависит от того, кому нужна оценка.
Оценка нужна:
1. Менеджеру проекта?
2. Оценка нужна заказчику?
3. Оценка нужна инвесторам?
1. Честно говоришь, что нет опыта, нужно N дней на прототипирование, после чего ты сможешь дать оценку с рисками.
2. Я бы не обманывал заказчика и не связывался бы с тем, в чем кроме теоретических знаний, ни чего нет.
Почему? Ну потому что заказчику нужно быстро, и он не готов оплачивать твое обучение.
Конечно же, если ты мастер в React или Angular, а заказчик хочет Vue, ну тут ни чего страшного нет, можно заложить 2-3 дня на прокачку Vue.
Но если ты ни когда не работал с ML или DSP, то браться за работу скорее всего не надо, будешь работать себе в убыток и карму попортишь.
3. Тут все проще, зависит от того сколько денег есть у инвесторов. Но опять же, что бы инвесторы были готовы отдать тебе свои деньги, нужен какой-то работающий прототип, соответственно ты уже не нуб
TMU>Можно хотя бы намекнуть, что за проекты с таким сроком реализации? Ведь через 10 лет будет одно сплошное телевидение весь технологический стек может поменяться?
Я бы, конечно, хотел бы это всё написать за 1-2 года.
У нас был большой пакет программ, написанный за лет двадцать или больше. На старых языках и на старых технологиях. С приходом новых операционок старые технологии начали отваливаться. Можно было бы менять старые технологии на новые в старых проектах, но мне было крайне неохота работать на старых языках, в старых IDE (там даже прокрутка колесом не работает, приходилось тыкать мышкой в скроллбар, Карл!), которые уже лет 10 не поддерживаются. Кроме того, рано или поздно этот код просто перестанет работать под новыми операционками, и нам, таки, придётся что-то с этим делать, и лучше начать делать заранее — вот с такими мощными аргументами я всех убедил, что надо бросать всё старое и зажигать всё новое. Саму систему, для которой этот пакет программ используется, хотят отправить на покой, но она лет пять ещё проработает точно, и людям, которые с ней работают, нужны инструменты, поэтому есть смысл делать это. Ну и вообще, мне это делать интересно
На счёт стека технологий — да, всё верно, на самом деле я постоянно в сомнениях, что выбрал всё верно. За часть я спокоен, а вот на счёт использования родного Windows UI — не очень. Но тут дело было ровно как у топик-стартера: если за родное UI я был уверен, что на нём можно сделать абсолютно всё и быстро, то если бы я взял за основу что-то иное, я не смог бы утверждать, что смогу сделать на нём всё, что потребуется. Т.е. тогда бы мне пришлось плотно разбираться с другими UI, получать хороший практический опыт, а на это надо время, которого и так мало
Re[5]: Как вы оцениваете затраты времени на разработку?
Здравствуйте, Евгений Музыченко, Вы писали:
CEM>>Я поступаю честно, иду и говорю заказчику: у нас такая-то проблема с таким-то браузером, у нас n вариантов решений, каждый со своими плюсами/минусами и своим сроком. Дальше мы вместе решаем, что с этим делать.
ЕМ>У меня в итоге так и получается. Думал, сообщество уже наработало какие-то другие шаблоны на этот счет.
Мне думается, это извечная проблема Да, в общем-то, такое её решение довольно нормальное, так что и не проблема вовсе
Нельзя предусмотреть всё, и все нормальные люди это понимают.
Re: Как вы оцениваете затраты времени на разработку?
Здравствуйте, white_znake, Вы писали:
_>1. Честно говоришь, что нет опыта, нужно N дней на прототипирование, после чего ты сможешь дать оценку с рисками. _>2. Я бы не обманывал заказчика и не связывался бы с тем, в чем кроме теоретических знаний, ни чего нет. _>Почему? Ну потому что заказчику нужно быстро, и он не готов оплачивать твое обучение. _>Конечно же, если ты мастер в React или Angular, а заказчик хочет Vue, ну тут ни чего страшного нет, можно заложить 2-3 дня на прокачку Vue. _>Но если ты ни когда не работал с ML или DSP, то браться за работу скорее всего не надо, будешь работать себе в убыток и карму попортишь.
Херня, всю жизнь меняю область деятельности, просто одна тема надоедает через какое то время. Никогда проблем не было. Причем не важно, это на обычном компе или на микроконтроллере. И даже в новых для себя областях никогда не задерживался более 6 мес в кодерах. Главное условие — тема должна меня интересовать сама по себе, а не деньгами.
Re: Как вы оцениваете затраты времени на разработку?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Как вы оцениваете затраты времени/нервов на разработку в той сфере, где еще не набили руку? Какие резервы закладываете, чтобы не попадать в цейтнот?
1. Разбиваешь задачу на подзадачи трудоемкостью не более 4-х часов.
Очень удобно в виде mind map или дерева. Дробишь ветки на листья до тех пор, пока не останется веток и все листья будут < 4 часа.
Почему 4? Потому что за день надо сделать два. А учитывая, что надо еще время на чай/туалет, остаются какие-то часа 3 — это вполне конкретный срок, который можно предсказать относительно точно.
Если что-то вообще не знаешь, сколько займет, гуглишь и разбираешься. Весь процесс может занять несколько дней.
2. Полученную трудоемкость умножаешь на 2.
Почему 2? Потому что ты выписал только видимую часть задач. В следующих проектах коэффициент можно скорректировать.
Дополнительная прелесть метода в том, что он позволяет точно отслеживать прогресс по задаче. То есть если например выполнено 50% видимой трудоемкости, то вполне можно предположить, что до конца проекта примерно столько же времени, сколько уже потрачено.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Re[2]: Как вы оцениваете затраты времени на разработку?
Здравствуйте, Basil2, Вы писали:
B>1. Разбиваешь задачу на подзадачи трудоемкостью не более 4-х часов.
Такое работает только в отношении задач, которые уверенно знаешь, как решать, от и до. Но в таких случаях я обычно и без детализации примерно представляю, сколько потребуется времени.
B>Если что-то вообще не знаешь, сколько займет, гуглишь и разбираешься. Весь процесс может занять несколько дней.
Разобраться — это полдела. Основные проблемы возникают на этапе стыковки своих модулей с подсистемой ОС, для которой они делаются, а там процесс бывает непредсказуем.
Например, осенью я делал фильтр DirectShow для устройств ASIO. Ни с тем, ни с другим раньше плотно не работал, только очень поверхностно. Но для ASIO-драйвера мой фильтр — это клиент, все управление идет от него, поэтому никаких особых проблем не возникло, только мелкие. А для графа DirectShow фильтр — это сервер, управление идет от графа. Документация у MS довольно убога, рассчитана на использование готового фреймворка Base Classes, на котором делает фильтры подавляющее большинство разработчиков. Я пару раз пользовался подобными фреймворками, но каждый раз имел от них проблемы в неочевидных случаях, и пришел к выводу, что проще было бы все сделать с нуля. В этот раз сделал с нуля, но поимел проблемы в других неочевидных случаях, когда из документации не было понятно, какие интерфейсы фильтр поддерживать обязан, а какие — нет. В итоге несколько реализованных интерфейсов так и не пригодились, поскольку причины проблем были в других местах.
Вообще, разработка модулей серверного типа (пассивно отвечающих на запросы клиента), при отсутствии подробной документации и средств тестирования — тот еще квест.
