Я часто ловлю себя на мысли, что установление сроков при написании программного обеспечения может иметь отрицательный эффект, хотя многие люди считают, что сроки полезны.
Мне кажется, их все же следует применять с осторожностью (как и любую другую таблетку счастья).
Я попытался проанализировать, как сроки могут навредить проекту и как сроки могут улучшить будущий результат. Для тех, кому лень читать всю статью: Я считаю, что сроки необходимы, но менеджеры и программисты должны понимать, что сроки иногда срываются, и что это не большая трагедия.
Иногда в срыве сроков виноваты обстоятельства, а не конкретные люди.
Наличие сроков для того, что вы делаете, полезно.
Но в случае с программированием есть некоторые нюансы.
Как сроки помогают писать программное обеспечение Благодаря срокам вы можете планировать будущее.
Если мы планируем закончить работу над функцией X за 2 месяца, то мы знаем, что через 3 месяца мы сможем выпустить новую версию нашего программного обеспечения.
Сроки помогают при рационализации/оптимизации: если мы знаем, что по срокам Петя заканчивает работу над фичей Х за 2 месяца, а Вася заканчивает работу над своей задачей за 2 дня, то нам легче разобраться, у кого сколько работы .
Если завтра появится какой-то баг средней важности, то мы можем рационально взвесить ситуацию и решить, что дадим исправить этот баг Васе, который освободится через 2 дня.
Сроки также могут выступать в качестве дополнительного способа конкретизировать задачу.
Программист может маневрировать под влиянием сроков — где-то он будет старательнее и чистоплотнее, а где-то нет. И это хорошо, потому что.
За счет таких маневров скорость разработки ПО в конечном итоге увеличится.
Как сроки мешают написанию хорошего программного обеспечения К сожалению, программирование — штука сложная, и даже хорошие специалисты не могут заранее правильно рассчитать сроки.
Кроме того, большинство программистов оценивают сроки слишком оптимистично.
Поэтому сроки часто срываются.
Получается, что программисту нужно вложить много эмоций и усилий, чтобы выполнить какую-то задачу в оговоренные сроки.
Программист может ставить неоправданно оптимистичные сроки под давлением менеджеров.
Еще хуже, когда менеджеры сами указывают программистам сроки.
В глазах многих программистов дедлайны — это своего рода карательный и укорительный инструмент для менеджеров.
У таких программистов дедлайны вызывают некоторый эмоциональный дискомфорт. Когда программист плохо себя чувствует на эмоциональном уровне, то, скорее всего, его эффективность снизится.
Когда программист видит, что не в состоянии выполнить задачу в требуемые сроки, он будет работать с повышенным усердием и повышенной концентрацией.
Я вижу из этого 2 следствия:
- Операционная маневренность программиста снижается.
Если он знает, что отстает от какой-то задачи, то в общей жизни рабочего коллектива займет более пассивную позицию – перестанет помогать новичкам, отмахнется от первого пришедшего в голову решения, когда оно необходимо.
чтобы обсудить будущую архитектуру.
Если над «просроченной» задачей работают несколько человек, то весьма вероятно, что каждый из них начнет перекладывать ответственность с одного на другого, т. к.
взять инициативу в свои руки и координировать действия в целом у них просто не будет времени.
взаимодействие.
- Программист, как и любой другой человек, устает. Если в среднем он написал 50 кг красивого кода, то под давлением сроков он начнет писать 75 кг красивого кода.
Но это не будет длиться вечно, он либо начнет писать 75 кг уродливого кода, либо рано или поздно «откатится» обратно к своей стандартной производительности в 50 кг красивого кода.
И сразу после сдачи этой просроченной задачи он, скорее всего, откатится в отрицательную сторону — по крайней мере, первые несколько дней он напишет всего 30-40 кг красивого кода.
Кто виноват? И как спасти ситуацию? Как обычно, истина лежит где-то посередине между менеджером и программистом.
С точки зрения менеджера я бы:
- Разрешили программисту самостоятельно называть сроки (если у нас это еще не так).
Если я вижу, что программист чувствует давление с моей стороны и пытается поставить слишком короткие сроки, то я постараюсь снять это давление — зачем мне передо мной программист, который ставит неправильные сроки?
- Следил за соблюдением сроков (спасибо ncix ).
Если на мой вопрос о сроках программист ответит: «О, это будет сделано через месяц».
Тогда я бы попросил программиста показать мне, как он планирует это сделать за месяц, на какие подэтапы он разобьет работу.
Насколько быстро он рассчитывает выполнить каждый из подэтапов.
- Установлен эмоциональный контакт с программистом.
- Тогда программист не будет чувствовать себя угнетенным, если застрянет в выполнении задачи.
Он просто пойдет к менеджеру и скажет: «Степаныч, то-то, у меня нет времени.
Что делаем? Предоставляем ли мы дополнительные ресурсы для выполнения задачи или переносим срокиЭ»
- Программист больше не будет чувствовать вину за нарушение сроков и будет более откровенен с менеджером.
Дедлайны перестанут быть карательным инструментом менеджера в глазах программиста.
- Тогда программист не будет чувствовать себя угнетенным, если застрянет в выполнении задачи.
- Я бы как следует следил за честностью и справедливостью в коллективе.
Поскольку я предлагаю высокий уровень доверия и свободы по отношению к программистам, возможно, найдутся программисты, которые попытаются окольным путем извлечь из этого выгоду.
Таких программистов следует исключить из команды, потому что.
они подрывают моральный дух.
- Я также установил эмоциональный контакт со своим менеджером.
Я не хочу прийти завтра к управляющему и сказать: «Степаныч, мне некогда.
» и бояться, что Степаныч сочтет меня ленивым.
- Я бы не давал слабину: когда они спрашивают о сроках и по лицам видно, что это нужно завтра, я бы старался не поддаваться эмоциональному давлению и трезво оценивал объем работы.
Если качество или скорость разработки программного обеспечения падают из-за политики компании в отношении сроков, то виноваты оба.
Использовать сроки необходимо и полезно.
Но мне кажется, что дедлайны должны быть снисходительными — сотрудники должны понимать, что им лучше «пропустить» дедлайн, если иначе они будут писать костыли или иначе будут эмоционально истощены.
Мы все еще не ясновидящие, а сроки всегда будут неточными, поэтому нам нужно быть готовыми к тому, что сроки можно корректировать.
Теги: #Управление проектами #сроки #Управление проектами
-
Алюминиевая Промышленность
19 Oct, 24 -
Решение Для Восстановления Outlook Pst
19 Oct, 24 -
Зима – Самое Жаркое Время Для Фрилансеров
19 Oct, 24 -
Вездеход Из Китая
19 Oct, 24 -
Microsoft Project Необходимо Удалить
19 Oct, 24 -
История Небоскребов
19 Oct, 24 -
Убить На Орм
19 Oct, 24
