Нет, такой таблицы нет, но идея отличная. Базовое время - t(баз) - примерный срок, в который я оцениваю задачу. Точная оценка задач - супер скилл, который можно всю жизнь развивать, так что такие методики (вышеупомянутая матрица, 1/2 длины окружности с радиусом t(баз)) призваны максимально уменьшить риск срыва срока.
Неважные задачи (те, которые заказчик не ждет так сильно) зачастую выпадают из контекста. Проект растет, увеличивается время внедрения нового функционала.
Навряд ли вы забудете или затянете реализацию функции, которую заказчик каждый день просит к столу)
Как раз пишу статью на эту тему, если коротко - пишу словами, так, чтобы понял и ребенок. В основном мое ТЗ состоит из юзкейсов, которые я вытягиваю из заказчика. По поводу нотаций - тут как совесть подскажет, потому что ТЗ может потом уйти другому разработчику. Если такой сценарий исключен - то хоть на иврите, как вам удобно)
Полностью согласен, отчеты ради отчетов и технологии ради технологий тормозят процессы как в командах, так и в сольных проектах.
Но ведение гита, правильное, не занимает много времени! Это полуавтоматическая процедура, коммит, мр.
Хот фиксы в обход регламентов похожи на снежный ком. В какой-то момент весь проект становится одним большим костылем, где под новую фичу проще написать с нуля вообще все .
Предлагаю сойтись на том, что важно сохранять разумный баланс)
Весь труд, который принесет заказчику профит - должен оплачиваться. Что насчет ТЗ?
ТЗ - это документация к системе. Хорошее ТЗ сэкономит много времени, как во время работы над проектом, так и при его поддержке, особенно если поддержкой будет заниматься другой разработчик.
Так что ответ - определенно да. Выносите в отдельный этап, договариваетесь об оплате этого этапа, объясняйте бизнесу всю выгоду от получения ТЗ.
Никаких платформ не использую, но всегда беру предоплату, как гарантию, что не уйду «ни с чем». Идеальный вариант - поэтапная оплата, хоть она и исключает радость от упавшей на счет «котлеты».
А так, если юридических ограничений нет, то можно и бэкдор себе оставить (осуждаем) =)
Параметр основан на личном наблюдении. Дело в том, что на важных вещах мы фокусируемся намного сильне и реже отвлекаемся. Критичные задачи обычно хорошо описаны, внимательно отслеживаются бизнесом / заказчиком, поэтому по ним труднее сорвать сроки. Отсюда и такой множитель для «неважных» задач
Привет!
Нет, такой таблицы нет, но идея отличная. Базовое время - t(баз) - примерный срок, в который я оцениваю задачу. Точная оценка задач - супер скилл, который можно всю жизнь развивать, так что такие методики (вышеупомянутая матрица, 1/2 длины окружности с радиусом t(баз)) призваны максимально уменьшить риск срыва срока.
Неважные задачи (те, которые заказчик не ждет так сильно) зачастую выпадают из контекста. Проект растет, увеличивается время внедрения нового функционала.
Навряд ли вы забудете или затянете реализацию функции, которую заказчик каждый день просит к столу)
Нет, к сожалению, не закрывает.
Но на своем опыте я с такими проблемами не сталкивался (самое страшное - задержки выплат)
Работаю как самозанятый
На первой официальной работе в IT компании получал 30 тысяч в месяц =)
Любить пожестче - не преступление =)
Хорошо, когда есть выбор)
Как раз пишу статью на эту тему, если коротко - пишу словами, так, чтобы понял и ребенок. В основном мое ТЗ состоит из юзкейсов, которые я вытягиваю из заказчика.
По поводу нотаций - тут как совесть подскажет, потому что ТЗ может потом уйти другому разработчику. Если такой сценарий исключен - то хоть на иврите, как вам удобно)
Вам спасибо!
Удачи в карьере!
Спасибо!
Спасибо!
Полностью согласен, отчеты ради отчетов и технологии ради технологий тормозят процессы как в командах, так и в сольных проектах.
Но ведение гита, правильное, не занимает много времени! Это полуавтоматическая процедура, коммит, мр.
Хот фиксы в обход регламентов похожи на снежный ком. В какой-то момент весь проект становится одним большим костылем, где под новую фичу проще написать с нуля вообще все .
Предлагаю сойтись на том, что важно сохранять разумный баланс)
Не пробовал, но спасибо, посмотрю)
Весь труд, который принесет заказчику профит - должен оплачиваться. Что насчет ТЗ?
ТЗ - это документация к системе. Хорошее ТЗ сэкономит много времени, как во время работы над проектом, так и при его поддержке, особенно если поддержкой будет заниматься другой разработчик.
Так что ответ - определенно да. Выносите в отдельный этап, договариваетесь об оплате этого этапа, объясняйте бизнесу всю выгоду от получения ТЗ.
Никаких платформ не использую, но всегда беру предоплату, как гарантию, что не уйду «ни с чем». Идеальный вариант - поэтапная оплата, хоть она и исключает радость от упавшей на счет «котлеты».
А так, если юридических ограничений нет, то можно и бэкдор себе оставить (осуждаем) =)
Самый первый - в профильном чате. Кто-то попросил помочь настроить пуши в приложении, я откликнулся, познакомился. Дальше сарафанное радио сработало.
Один из проектов получил через рекомендацию от бывшего лида.
Одним словом - нетворкинг)
Да, приходилось. Прошло не совсем гладко, но удалось выбить дополнительную оплату.
В целом, убеждать бизнес в его неправоте - дело неблагодарное, так что тут любое подспорье кстати.
Параметр основан на личном наблюдении. Дело в том, что на важных вещах мы фокусируемся намного сильне и реже отвлекаемся. Критичные задачи обычно хорошо описаны, внимательно отслеживаются бизнесом / заказчиком, поэтому по ним труднее сорвать сроки. Отсюда и такой множитель для «неважных» задач
Ютрек, в последнее время кайтен. Тарифы везде бесплатные, так как только 1 сотрудник