Как я неправильно запланировал задачу и что из этого получилось
В предыдущем посте я описал гипотетический пример неверной постановки задачи. Давайте для наглядности обратимся к реальной практике :)
Вот пример из жизни того, как надо неправильно ставить задачу - было это примерно в январе 2010.
В связи с одной из моих глобальных целей мне нужно было установить и протестировать кластер на Ubuntu Linux Server с базой данных MySQL. Итак, при планировании я сделал следующим образом:
Первоначальная планировка целей:
Понедельник: установка кластера MySQL 50% - 2 часа;
Вторник: установка кластера MySQL 50%. Документирование процесса установки - 2 часа;
Среда: поиск механизмов тестирования производительности СУДБ MySQL - 2 часа;
Четверг: установка теста и проведение тестирования кластера MySQL. Описание в документе установки теста и анализа результатов - 2 часа.
Остальное время недели было распланировано практически на 100% (еще одна моя ошибка из тех, которые описал в посте О пользе обратной связи в планировании. Часть 1)
Что у меня получилось (тут уже буду измерять днями/неделями, а не часами :) )
1. На поиск первоначальной информации о кластерной архитектуре баз данных и изучение материалов у меня ушло примерно 8 часов (до этого знания в этой области у меня были минимальны). С учетом прочей загрузки недели у меня на это ушла почти неделя (5 дней);
2. Установка кластера удалась с 3й попытки, всего было потрачено 6 часов чистого времени. В рамках прочей загрузки недели на это ушло 3 дня;
3. Документирование процесса установки - 1 час;
4. Поиск вариантов тестирования MySQL базы данных. Здесь открылся еще один сюрприз. У меня достаточно большой опыт работы с СУБД MS SQL Server 2005 под MS Windows. Там графический интерфейс, настройка и прочие вещи устроены так, что работать с ними визуально комфортно. Здесь же что-то вроде командной строки. Таблиц, представлений, процедур и функций сразу не видно, нужно использовать консольные команды, чтобы получить их список. В общем, мне пришлось искать книжки по MySQL и поверхностно изучить его, на что ушло 3 часа (в сумме с 3й задачей получилось еще 2 дня);
5. Теперь я немного начал разбираться в том, что вообще следует искать для проведения теста - программу для автоматизации наполнения базы данных информацией. На ее поиск и настройку у меня ушло 4 часа, то есть 2 дня;
6. Поиск теста либо написание своего. На поиск ушел 1 час. Установка и настройка теста: 3 часа, итого снова 2 дня;
7. Проведение тестирования: 1 час;
8. Документирование полученных знаний: 2 часа. Итого, если прибавить время 7й задачи и округлить, снова получается 2 дня.
Время подвести итоги :)
На задачу, которую я планировал сделать за 8 часов, то есть 4 дня у меня ушло 16 дней - это большая половина месяца. В результате я поплатился тем, что сильно провалил свои сроки, получил хороший заряд демотивации. Снизился общий тонус. Увеличилось время выполнения смежных задач. Влияние этой ошибки продолжало сказываться на мне в течение 2 месяцев - на первом производительность упала на 30% (по сравнению с предыдущим), на втором упала ДО 30% !!! Потом начала восстанавливаться, но достаточно медленно.
Об анализе своих ошибок напишу в следующем посте, можете пока сами подумать о них :)
Вот пример из жизни того, как надо неправильно ставить задачу - было это примерно в январе 2010.
В связи с одной из моих глобальных целей мне нужно было установить и протестировать кластер на Ubuntu Linux Server с базой данных MySQL. Итак, при планировании я сделал следующим образом:
Первоначальная планировка целей:
Понедельник: установка кластера MySQL 50% - 2 часа;
Вторник: установка кластера MySQL 50%. Документирование процесса установки - 2 часа;
Среда: поиск механизмов тестирования производительности СУДБ MySQL - 2 часа;
Четверг: установка теста и проведение тестирования кластера MySQL. Описание в документе установки теста и анализа результатов - 2 часа.
Остальное время недели было распланировано практически на 100% (еще одна моя ошибка из тех, которые описал в посте О пользе обратной связи в планировании. Часть 1)
Что у меня получилось (тут уже буду измерять днями/неделями, а не часами :) )
1. На поиск первоначальной информации о кластерной архитектуре баз данных и изучение материалов у меня ушло примерно 8 часов (до этого знания в этой области у меня были минимальны). С учетом прочей загрузки недели у меня на это ушла почти неделя (5 дней);
2. Установка кластера удалась с 3й попытки, всего было потрачено 6 часов чистого времени. В рамках прочей загрузки недели на это ушло 3 дня;
3. Документирование процесса установки - 1 час;
4. Поиск вариантов тестирования MySQL базы данных. Здесь открылся еще один сюрприз. У меня достаточно большой опыт работы с СУБД MS SQL Server 2005 под MS Windows. Там графический интерфейс, настройка и прочие вещи устроены так, что работать с ними визуально комфортно. Здесь же что-то вроде командной строки. Таблиц, представлений, процедур и функций сразу не видно, нужно использовать консольные команды, чтобы получить их список. В общем, мне пришлось искать книжки по MySQL и поверхностно изучить его, на что ушло 3 часа (в сумме с 3й задачей получилось еще 2 дня);
5. Теперь я немного начал разбираться в том, что вообще следует искать для проведения теста - программу для автоматизации наполнения базы данных информацией. На ее поиск и настройку у меня ушло 4 часа, то есть 2 дня;
6. Поиск теста либо написание своего. На поиск ушел 1 час. Установка и настройка теста: 3 часа, итого снова 2 дня;
7. Проведение тестирования: 1 час;
8. Документирование полученных знаний: 2 часа. Итого, если прибавить время 7й задачи и округлить, снова получается 2 дня.
Время подвести итоги :)
На задачу, которую я планировал сделать за 8 часов, то есть 4 дня у меня ушло 16 дней - это большая половина месяца. В результате я поплатился тем, что сильно провалил свои сроки, получил хороший заряд демотивации. Снизился общий тонус. Увеличилось время выполнения смежных задач. Влияние этой ошибки продолжало сказываться на мне в течение 2 месяцев - на первом производительность упала на 30% (по сравнению с предыдущим), на втором упала ДО 30% !!! Потом начала восстанавливаться, но достаточно медленно.
Об анализе своих ошибок напишу в следующем посте, можете пока сами подумать о них :)