переключение контекста

Периодически наблюдаю заказчиков, недоумевающих — почему поменять картинку на сайте занимает два дня? Как получается, что баг не исправляется неделю? Почему вы не отвечаете на мой вопрос в скайпе в течении 2 минут?

Есть несколько причин, и одна из них — в переключении контекста.

Представьте себе, что у вас есть задача — прочитать две страницы книги. Сколько времени это займет? Минут 5, от силы.

Усложним задачу. Теперь вы в течении дня занимаетесь каким-то своим делом, и к вам периодически подходит некто, и просит прочитать одно слово, выбранное случайным образом из тех же двух страниц. В общем-то объем работы не поменялся (те же две страницы текста), но затрат времени стало несколько больше — вам уже нужно:

1. вспомнить, о чем речь,
2. довести текущее дело до этапа, где можно прерваться,
3. найти книгу,
4. найти страницу в книге,
5. найти слово в книге,
6. прочесть слово,
7. вернуться к прерванному делу.

Сделаем задачу ещё сложнее. Для выполнения задачи вам необходимо, чтобы один человек держал книгу, второй искал страницы, а третий показывал слова, четвертый читал. Что меняется? Если мы читаем все слова сразу — почти ничего: мы даже можем получить выигрыш по времени, если команда — слаженная. Но если берем второй вариант, с переключением… то возникают дополнительные потери времени за счет разной продолжительности 2 этапа (время завершения текущих задач у наших троих сотрудников будет разным) и аритмии (сложно настроиться шагать в ногу, если делать нужно только один шаг). Большинство технологических процессов в IT — именно такие, предполагают участие нескольких специалистов.

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

Например, мы:

1. стараемся не брать проектов продолжительностью меньше 1 месяца (особенно с новыми клиентами). По опыту могу сказать, что на неделю программирования может приходиться в 2-4 раза больший срок согласования — апробации — приемки — отладки (то есть тех этапов, где есть взаимодействие с клиентом). Именно поэтому нарушение данного пункта может сделать проект нерентабельным, либо просто сильно повысит расценки в его рамках.

2. минимизировать количество этапов проекта (в проектах продолжительностью меньше 4 месяцев их пять: составление техзадания, разработка прототипа, апробация у клиента, доводка до финальной версии, отладка). Объяснять долго, но вкратце: увеличение количества этапов в общем случае не столько повышает управляемость процессом, сколько даёт множество поводов для взаимных претензий, обеим сторонам. Яркой иллюстрацией этому был один мой товарищ, который оговорил еженедельную (!!!) сдачу этапов клиенту в проекте продолжительностью полгода. Угадайте, как скоро они поссорились и разошлись? Ровно через неделю.

3. заранее предупреждаем, что в наши расценки входит некоторый бесплатный объем доработок, но лишь в случае немедленной реакции клиента (в рамках оговоренного срока апробации) на переданную ему версию продукта. Говорим, что нам выгоднее/эффективнее выполнить 100 пунктов замечаний, но сразу — чем 50 пунктов, выданных порциями по 5.

Резюме: работайте пакетами. Это эффективно в любом виде бизнеса.

24.02.2011   Бизнес   Комментариев нет

Оставить комментарий