Комментарии 13
Мне кажется, весь ответ уже есть в заголовке:
Почему оценки у всех подрядчиков разные? Ведь задача понятна и ясна…

Как раз почти всегда не понятна и не ясна, причем часто не ясна даже для заказчика. Отсюда и «тз» используется лишь как слово, а в реальности я чаще всего на входе имею зарисовки частично противоречащих друг другу идей (может у кого по другому?). Их можно трактовать сотнями различных вариантов.
Спасибо за ответ. Можете не много описать подробнее: «Частично противоречащих друг другу идей»- Вы их берёте из ТЗ или собственного опыта?

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

Повторите задачу, например, строительство жилого дома на загородном участке по типовому проекту сотню раз и ваши оценки по выполнению таких задач станут точными.
Так с типовыми проектами проблем обычно и нет. А вот когда всё под индивидуальный заказа, а то что строить надо было на Марсе, а не в Подмосковье, выясняется уже в процессе, опыт мало помогает. Разве что, заставляет всегда закладывать возможность постройки на Марсе.
Спасибо большое за ответ.
«строительство жилого дома на загородном участке по типовому проекту сотню раз» — я как раз для этого старался ввести ограничения к статье про ИТ решения и процесс их разработки. Возможно надо добавить слово Custom. Но, понимая что ваш пример синтетический, я с вами в целом соглашусь. При этом, хочу заметить что в современном мире, учитывая особенно текущую ситуацию, есть тенденция на то что «Проектов» как таковых становится меньше и компетенции к адаптации необходимы всё больше и больше. А это в свою очередь влияет на трудность воспроизведения своего опыта и повторения оценки.
В статье описан больше сценарий исследовательской разработки. Даже перед тем как вы сможете что-то повторить 100 раз, вам необходимо будет пройти первые фазы (Gartner Hype Cycle for Emerging Technologies тут как пример может выступать), когда вы будете вырабатывать решение. И тут в зависимости от индустрии, срока жизни и изменчивости среда будет в любом случае меняться
«А самое главное, люди, носители этого опыта, поменяются, кто то уйдет, кто то обленится» — Ну так поэтому я и старался писать так же и о деятельности распространения знаний. Словом «культура» тут можно многое описать, но если в этой «культуре» нет системной деятельности по распространению знаний, то и «культура» не поможет.
Почему оценки у всех подрядчиков разные? Ведь задача понятна и ясна…

Я на это обычно отвечаю: потому что подрядчик решает свою проблему, а не вашу.
Это печально ))


… а если вы хотите чтобы подрядчик решал именно вашу проблему — то досконально до полного занудства обсудите с ним проект.

На что мне отвечают: «Ты же специалист, ты и сам должен знать».
На что я отвечаю: «ОК. Сделаю так как я вижу. Но чтобы без претензий. Все доработки — за отдельные деньги, и это будут не копейки».
Тут начинают задумываться…
Иногда выбирают не меня, а того, кто им меньше полощет мозг.

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

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


Это же зависит только от сложности (и соответственно стоимости) разработки.

Если мелочи — то фиг с ним. Делаем бесплатно. Это нормально.

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

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

Вот кипа таких мелочей и уже месяц работы. На все бесплатные мелкие хотелки, ни сил, ни времени нет

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