Свой проект пока оставил, т.к. на мне висела еще одна задача. Доделать google парсер на тему политики для местного заказчика.  И только если останется время — протестировать нишу своего проекта. Забегая вперед скажу, что протестировать я не успел. Как это часто бывает доработка затянулась и сдачу пришлось перенести на завтра. С этим связано пара интересных наблюдений:

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

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

2013-10-29 08.41.50

2.  Второй интересный момент — это характер поведения проекта. Если брать не поставленную систему проектов, то интенсивность её поведения можно описать так (см. рисунок). То есть заказчик говорит — надо все и срочно — ты начинаешь искать информацию и спецов, работать, выдавать результат к этому моменту, успеваешь в попыхах и недосыпая последнюю ночь, отправляешь на проверку — и ждешь ответа 3 дня в течение которых у заказчика просто не нашлось времени чтобы зайти и посмотреть.
Далее цикл доработок — и снова по той же схеме. Только в этот раз, когда заказчику задаешь дополнительно появившиеся вопросы — на них можно ждать ответа в течение от пары дней до нескольких недель.

В «умных» книгах пишут, что нужно задавать вопрос. А почему такая срочность, а какое событие определяет срочность. Дополнительно можно вырабатывать инструмент разговора с заказчиком, договорившись, что во вторник и четверг с 18 до 18:30 вы с ним общаетесь по проекту. И объяснить важность этого проекта. Еще из успехов дня — это выполнение мелких дел, которые откладывал по от 1 месяца до 2-х лет. Это результат написания полного перечня всех дел, висящих на мне. И пожалуй все.

И третья история, точнее даже модель поведения, про которую я хотел рассказать называется «Принять решение об остановке». Представьте — у Вас есть срок, вся команда его знает и работает чтобы к нему успеть за пару дней до срока уже почти все готово, только остались мелочи, в день сдачи осталась последняя ошибка, с которой показывать нельзя, но её вот вот исправят. И вы всей командой ищете эту ошибку. Ошибку находите, но там еще одна небольшая (а время уже 17 часов — близиться к завершению рабочего дня, а показать вы должны именно сегодня) Вы уведомляете заказчика, что вот вот — осталась последняя ошибка и все покажем, проходит час, другой. Ошибку уже кажется нащупали, но что-то где-то еще не до конца… Третий.  Вот такую ситуацию представьте — думаю у каждого она была. По крайней мере у меня за практику думаю раз 10 точно была. Так вот — в этих ситуациях нужно принять решение остановиться. Вы ставите срок — говорите если за 20 минут не находим, значит сегодня уже не находим. Через 20 минут вы не находите. Тогда, не смотра на то, что ребята говорят вот вот все запустим — вы с грузом на душе, но все же собрав волю в кулак  звоните заказчику и договариваетесь о переносе просмотра. А команду распускаете по домам. Продолжение будет следующее — буквально через 5 минут команда находит эту ошибку и показывает Вам результат. Но вы не обольщайтесь, потому что где-то в другом месте еще сломалось и сегодня вы в любом случае  не покажете.

Я пока не на столько силен в психологии и не могу объяснить всего произошедшего, но это правильная модель поведения. И она проверена на практике.

А тем временем задумывайтесь почему такое вообще произошло. Вы не установили Redline (редлайн — черта перед deadline с запасом на риски. Устанавливается для себя, а подчиненным сообщается как deadline) не делали сборку раньше, не писали тестов, причины могут быть различные, но то что описано вышел — это следствие. И Ваша задача, как руководителя — предвидеть эти следствия и устранять причины.

Расскажи друзьям

Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс