Доброго дня, уважаемые коллеги!
Долго думала, не могла решиться написать данную статью. И дело вовсе не в том, что я молодой специалист и боюсь негативной критики и неудобных вопросов. =) Дело в сборе информации, и анализе полученного опыта. Делать вывод хорошо, когда есть не только положительные результаты, но и отрицательные, не правда ли? Поэтому сбор информации происходил долго, размышления и умозаключения заняли не мало вечеров, а иногда и бессонных ночей.
Думаю, наконец стоит приступить к изложению.
Когда я начинала свою карьеру разработчика XMind позиционировалась как основной инструмент тестировщика. В нем было удобно «накидывать» чек-листы, видеть общую картину, а также при возможности видеть детали (дойдя до низших уровней иерархии). В случае ошибок, легко было прикрепить скриншоты. А переслав карту тестирования разработчику, можно было свести к минимуму наводящие и уточняющие вопросы. Разработчик видел при каких обстоятельствах возникала ошибка, видел саму ошибку. На этом функциональность программы ограничивалась, больше ей никто не пользовался. Была куча других разных сторонних утилит, позволяющих следить за временем, планированием и прочими «плюшками».
Скажу честно, я пробовала практически все, что советовали коллеги, они так красочно описывали плюсы программ, которыми пользовались сами. Как эти программы упростили их жизнь, как все стало просто и легко, время перестало улетать в небытие, мне хотелось того же. Ведь мое время тратилось не понятно на что, вечная паника из-за дедлайна (конечно, не малую роль играли отсутствие опыта и неуверенность в себе). Вечно ускользающие мелочи при разработке, которые потом вылезали огромными косяками, править их приходилось по ночам. А не способность оценить текущую ситуацию и сроки сдачи задач делали меня беспомощной. Все это накладывалось одно на другое, и постепенно привело меня в страну уныния и рутины. Рабочий день продлевался до 12-14 часов в сутки, очередной вопрос о сроках сдачи задач ставил в тупик.
Стоит отметить, что в разработчики я перешла из бизнес-аналитиков, а туда из тестирования. Пока училась в институте, любая работа была желанной, и поэтому пришлось пройти путь с самого начала (что я считаю огромным плюсом для себя).
Итак, попав в ловушку своей неопытности и рабочего «завала» я начала мыслить по-другому. Однажды, пришлось тестировать доработку другого разработчика, автоматически я открыла забытую, запылившуюся на рабочем столе иконку XMind. Быстро «накидав» план тестирования, и пройдясь по новому функционалу, я отчетливо поняла для себя, что эта задача не ввергла меня в ужас и в общем то была сделана очень оперативно, а главное в срок.
- "Можно ведь использовать карты и для разработки, и для планирования..." - Эта, казалось бы, очевидная мысль, стала для меня целым открытием. Я много читала статей о систематизации своего времени, пыталась воплотить их в жизнь. Как правило, люди, писавшие эти статьи, имеют ненормированный рабочий день и могут позволить себе отвлечься, прогуляться или переложить какие-то задачи на завтра. В моем случае это было неприемлемо, 8 часовой рабочий день, куча задач, и всегда появляющийся неожиданно из неоткуда дедлайн =). Нужна была система, которая помогла бы увидеть всю картину, где находишься в текущий момент, что необходимо сделать сейчас и какие параллельные задачи будут затронуты.
Первое к чему я себя приучила - это заводить на каждую задачу новую страницу (доску). Кто - то скажет, что это в корне неверное решение, но для себя я выбрала именно такое (возможно в дальнейшем я его и поменяю, но пока мне так удобнее). Дальше, читая функциональные требования (а заказчик присылает именно их, ибо сформулировать техническое задание не в состоянии) составлялось нормальное, проработанное техническое задание. На своей карте я разбивала задачу на подзадачи, т.е., например, основная "хотелка" заказчика: "Я хочу новый документ, чтобы у него было вот столько - то вкладок, кнопочки такие цветные, разные. И чтобы при нажатии на каждую у меня все делалось само, и радуга за окном". В своей карте я создавала новую доску и выглядела она следующим образом.
Далее шла более детальная проработка каждой из подзадач, иногда приходилось разбивать ее на еще более мелкие. Здесь стоит отметить, что излишняя увлеченность деталями и генерация тысячи подзадач - имеет плохие последствия (например, внесение изменений в ветвь, несет полный пересмотр подчиненных объектов, а это значит, чем больше подчиненность, тем сложнее что-либо изменить или исправить), поэтому разбиение на задачи имеет условный характер. Скажем, разбиваем так, чтобы было понятно, о чем идет речь и что туда входит. При желании можно указывать тип данных, я их указываю, для того чтобы при создании сразу "накидывать" все необходимые реквизиты и далее не возвращаться к этому вопросу.
Постепенно карта становилась больше, и подробнее.
После проработки структуры задачи и ее вложений можно переходить к самой разработке. Я разрабатываю обычно по порядку, иду с верху вниз задача за задачей. Параллельно выполняя их, прикрепляю скриншоты результата, оставляю комментарии или вопросы, возникшие в процессе работы. Так же помечаю каждую задачу маркерами, чтобы быстрее ориентироваться в них и видеть текущее положение дел.
Последовательно выполняя задачу за задачей и помечая спорные моменты, я организовываю свой рабочий процесс таким образом, что в случае неожиданной встречи я буду иметь представление об общей картине и видеть процент выполнения конкретной задачи. Смогу оперативно сориентироваться по вопросам заказчика. Иногда бывает, что у заказчика всего 5 минут свободного времени, а уточнить нужно многое. Не имея четкого плана и пометок, можно упустить важные моменты или не задать важных вопросов. В случае, когда, начальник спрашивает о сроках сдачи доработок, я показываю ему свой план разработки и наглядно демонстрирую какие возникали трудности, где сейчас остановилась и что еще необходимо уточнить или разработать.
Плюс такого подхода еще и в том, что после разработки задачи ее передают на тестирование, другому человек (во многих больших IT компаниях существует отдельный отдел тестирования). В таком случае очень много времени уходит на то, чтобы объяснить, что именно ты разработал, для чего и что нужно сделать чтобы протестировать данную задачу. Не редко приходится назначать отдельную демонстрацию и показывать, что и как работает. В таких случаях моя карта выручала меня не раз =). Я отправляла план разработки тестировщику, он видел все пункты, видел, что должно получиться в результате, а главное знал, какие объекты были затронуты помимо непосредственно разработанных. Часто приходится тестировать больше, чем разработано, ведь главное не просто создать что-то новое, но и не сломать старое. Работая без плана, можно наделать уйму ошибок.
Вот такая не сложная система была разработана мною для оптимизации своего рабочего времени и упрощения процесса разработки и тестирования. Она помогла мне точно знать, чем заниматься, какие трудности могут возникнуть в процессе разработки, что нужно продумать дополнительно, избегая судорожных исправлений по ночам и опозданий со сдачей доработок. Помогло лучше разделять свое время на задачи, реальнее оценивать сроки и говорить предметно с заказчиками. Времени, конечно, больше не стало, но зато теперь я смело могу ответить на что конкретно его трачу и внутренний голос больше не орет в панике, что мы ничего не успеваем.
Надеюсь, моя история будет полезной, для людей, находящихся в поисках своей идеальной системы оптимизации. Спасибо за внимание =).
