Альтернативы методологии отслеживания времени [закрыто]

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

Объяснение:

Я работаю в компании, где мы работаем так. Всем платят зарплату. У нас есть 3 вида работ: контрактная, временная и внутренняя (неоплачиваемая). Adhoc - это просто небольшие изменения, которые занимают несколько часов, и мы просто выставляем счет клиенту в конце месяца. Контракты подписаны, и у нас этот большой длительный процесс, обычный.

Мы выясняем, сколько нужно зарядить, получая оценку затраченного времени (от дизайна и разработчиков), умножая его на нашу почасовую ставку и все. Скажем, мы оцениваем 50 часов для веб-сайта. У нас есть программное обеспечение для отслеживания времени, и мы должны записать время в 15, которое мы тратим на него (например, с 7:00 до 7:15), название проекта и дать ему некоторые комментарии.

Теперь, если мы пройдем более 50 часов, мы оба теряем деньги и неэффективны.

Теперь , когда я объяснил, как работает система, мой вопрос заключается в том, как еще это можно сделать, если существует лучший метод (который, я уверен, должен). Никто здесь не любит нынешнюю систему, мы просто не можем найти альтернативу. Я был бы более чем готов работать после нескольких часов дольше над проектом, чтобы выполнить его вовремя, но я очень склонен делать это с нынешней системой. Я бы хотел, чтобы мой менеджер мог подвести итог (или ссылку) на этот пост, чтобы показать им, почему мы должны использовать систему abc вместо этой системы.

Оценка программного обеспечения всегда сложна. Программное обеспечение - это творческий бизнес, а творчество развивается и исчезает. Я только начинаю приходить в себя после недели сильного истощения - вчера вечером мне потребовались часы, чтобы выполнить задание, которое должно было занять 15-30 минут ...

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

В своем личном консалтинговом опыте я стараюсь сочетать реалистичную оценку с потолком. В основном говоря: «Я ожидаю, что эта функция займет 7-10 часов, но может достигнуть 18 - максимум, даже если это займет 40 часов, вам выставят счет на 18». Обычно этот тип подхода является новым для клиентов, и некоторые отказываются от него с «дать мне твердую цену» - эти клиенты получают максимальную оценку (или я вежливо отказываюсь от их бизнеса). Для клиентов, которые принимают этот подход, они понимают, что я буду честно отслеживать время, и их фактический окончательный счет будет отражать мое потраченное время (но не превысит мой потолок). По сути, это бережливый подход с добавленной гарантией; и клиент знает, что любые изменения в требованиях вносят изменения в оценки.

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

Если нет, я бы посоветовал прочитать «Мифический человеко-месяц»

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

В течение последнего года или около того в Fog Creek мы разрабатывали систему, которая настолько проста, что даже наши ворчливые разработчики готовы согласиться с ней. И, насколько мы можем судить, он производит очень надежные графики. Это называется доказательным планированием, или EBS. Вы собираете доказательства , в основном из исторических данных расписания, которые вы возвращаете в свои графики. То, что вы получаете, это не просто одна дата отгрузки: вы получаете кривую распределения уверенности, показывающую вероятность того, что вы отправите в любую данную дату. Это выглядит так:

Чем круче кривая, тем больше вы уверены в том, что дата корабля реальна.

Вот как ты это делаешь ...

Проблема этого метода заключается в том, что он не учитывает неотъемлемый риск в оценках. Лучшая практика для любых оценок состоит в том, чтобы выразить это как диапазон времени, например, 50 часов ± 15 часов, или что-то подобное. Сложно придумать термин ошибки, но никто не верит, что в любом случае это займет ровно 50 часов.

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

Мы делаем оценки с фактором «неопределенности», а не пытаемся оценить с помощью факторов «+/-». Программисты могут легко сказать, сколько времени займет что-то, «если ничего не случится». То, что они не могут легко сказать вам, это то, сколько времени потребуется, если что-то пойдет не так. Таким образом, мы добавляем коэффициент неопределенности - «L» означает «добавить 25%» - «M» означает «добавить 50%», а «H» означает «добавить 100% - может удвоиться». Реальное время обычно находится между расчетным временем и оценкой плюс время неопределенности.

Что касается отслеживания вашего времени, самый точный метод - это написать программу, которая каждую минуту открывает диалоговое окно и спрашивает вас «что вы делаете?» С выпадающим списком возможных задач. Единственная запись, которая вам действительно нужна в этом раскрывающемся списке, - это «время отслеживания», потому что, если вас прерывают каждую минуту, вы больше ничего не сделаете. Тот же принцип применим и к 15-минутным интервалам, но не так плохо.

Мы запускаем небольшую программу, которая позволяет нам добавлять задачи в список и выбирать, над которой мы работаем, позволяя ему добавлять время. Если мы забудем переместить селектор на нужную задачу, итоги будут редактироваться. Все, что не находится в одном из рядов, переходит в «разное». Это не совсем точно, но общая точность менее важна, чем получение времени потока.