Как быть если, все разработчики загружены, но постоянно «вклинивается» неотложка из-за которой страдают сроки по проектам?

Question

[Roquie]

Банальная ситуация - есть несколько разработчиков, у каждого по проекту и у каждого свои сроки. В процессе их выполнения возникает неотложка на 15 минут - 5 часов, которую надо выполнить "здесь и сейчас". Из-за этого, порой сильно, страдают сроки конечных продуктов. Как быть? Постоянно уведомлять заказчиков? - Замотаешься. Увеличивать сроки разработки с учетом рисков? ... странная затея, если риски не относятся к проекту заказчика. Они же не резиновые. Вот и напрашивается сей вопрос.

Возможно он классический. Приму любые замечания и ссылки.

Answer 1

[dmitriy]

Выделите людей которые будут заниматься неотложкой на регулярной основе. Тем самым рабочая группа занимающаяся запланированными задачами не будет отвлекаться на не предвиденные задачи. Задачи в формате неотложки выполняются в рамках поддержки продукта.

Comments

[Roquie]

Для текучки, человек уже выделен. А задачи по неотложке требуют более быстрой сообразительности и знания всей системы. Отдавать людей, коих немного, на постоянную основу - расточительно :(

Answer 2

[Пума Тайланд]

Любая неотложка продается просто в три раза дороже, этого хватает на то чтобы взять ещё одного двух трех программистов сверху.

Comments

[Roquie]

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

[Пума Тайланд]

Если простой по моей вине, то это не срочная правка, а ожидаемая с уже заложенным временем.
Любые действия в итоге за счет заказчика, если сервис на поддержке то он и так платит и можно нанять отдельного человека для этого, если не платит то какая тут может быть моя вина если с сервисом я ничего не делал.
Сказать честно я не очень понял ваши доводы.

[Roquie]

Пума Тайланд: Скажем так, все проекты находятся в единой экосистеме, которую мы поддерживаем. Например, отвалится модуль платежей, соответственно со всех проектов на нем завязанных мы несем убытки, за то, что кто-то денег недополучил.
К тому же, мы сотрудничаем с другими отделами разработки (для коннекта между продуктами). Выходит так, что одни пинаю на других, другие на нас. Как в детсаде. И как правило никто ничего не трогал :) А процесс выяснения, кто "козел" занимает уйму времени.

[Roquie]

пинают*

[Пума Тайланд]

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

[Пума Тайланд]

Это все договорные отношения и опять таки юлипс имеет в виду одно, а Роки работает совсем в другой области, где отношения другие.

Answer 3

[Антон Пискунов]

Неотложка возникает относительно чего? Вот у меня есть продукт "А" и я его делаю. Херакс, неотложка, она куда применима? К проекту "А"? К проекту "Б" которым занят Петя сидящий слева? К проекту "Ж" который давно сдан?

Comments

[Roquie]

Проект Ж. Он, например, мог неожиданно упасть, причем не по нашей вине. Но пока выяснят, кто виноват уйдет приличное время...

[Freeman]

Тут просто нужны отдельные люди на поддержку/сопровождение проектов.

[Roquie]

Vapaamies: Согласен. Но пока стоит задача решить проблему без высоких затрат. Сейчас никого нанимать не будут....

[Freeman]

Roquie: Ниже уже предложили взвинтить цены на неотложку в три раза.

Answer 4

[Владимир Фокин]

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

+ Подправили проект, заказчику не надо искать фрилансеров или студию.
+ Заработали копейку.
- Потеряли время.

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

Comments

[Roquie]

Оно работает, только в идеальном мире... Очень часто наблюдаю ситуации - сделайте это здесь и сейчас, надо срочно, "всего пару минут" ... и такие заказчики находясь, буквально в трех метрах, сильно возникают, что ж так за такие мелочи составлять ТЗ, утверждать его, когда проблема горит.

[Freeman]

Roquie: Это ваш организационный и бизнес-прокол. Заказчики не должны находиться в трех метрах от разработчиков. Не сможете решить -- разоритесь, и это будет логично.