Постепенно делать vs Нахрапом делать

Два распечатанных и не принятых тома из четырёх.

Два распечатанных и не принятых тома из четырёх.

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

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

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

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

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

Или подготовка к экзаменам. Очень часто удавалось выучить огромные пласты информации: цифр, дат, формул и утверждений буквально часов за 12. Я никогда не забуду как подготовился к статистике за 12 часов. Там было порядка 90 вопросов. То же относится и к отечественной истории и многим другим предметам. Правда, всегда учить проще, когда до этого была полноценная и регулярная работа по данному предмету.

Мне всегда нравилось решать сложные задачи нахрапом, буквально за один присест. Но практика показала, что не всё возможно решить таким способом.

Например, курсовой проект по проектированию информационных систем. До этого я успешно выполнял курсовые по базам данным, бухгалтерскому учёту, информатике и программированию, матэкономике буквально за 1 неделю вечерами. Чаще всего я плотно сидел пару выходных или даже пару вечеров, а потом ещё немного дорабатывал эти проекты и успешно сдавал. Чаще всего на «5». А как-то раз я и вовсе сумел помочь сделать курсач по программированию часа за 4. Также на счету реализация практической части одного диплома за три вечера после работы.

Но всё изменилось когда дело дошло до «Проектирования Информационных Систем». Оно же «ПИС». Говорящее название, надо заметить. Когда я смотрел как суетятся мои одногруппники ещё в начале мая относительно этого курсовика, мне казалось что паника слишком несвоевременна. Как же я ошибался. Как же я заблуждался!

Когда я целую неделю просидел только с первой частью, в которой я занимался такими вещами как описание предприятия, на котором я проходил летнюю практику. Это кажется на словах просто, но когда нужно описать:

- виды деятельности;
- основные производственные фонды;
- производственные и экономические показатели;
- входные ресурсы;
- детальную характеристику трудовых ресурсов;
- организационную структуру (со схемой);
- физическую структуру расположения предприятия (со схемой);
- центровые бизнес-процессы предприятия, их описание и классификацию;
- систему управления предприятием, её стандарты;
- состав и структура действующей информационной системы предприятия и её стандарты;
- логическую и физическую схему компьютерной сети;
- новые проекты предприятия;
- проблемы, решение которых актуально для фирмы.

После того, как у меня на это ушла битая неделя (правда уделял курсовику время только вечерами) и вышло около 90 страниц, я серьёзно призадумался, а смогу ли я всё успеть? Шла зачётная неделя, а впереди ещё 4 части, большинство из которых сопоставимы по объёму с первой, но значительно сложнее по наполнению.

Представьте себе 15 бизнес-процессов предприятия. У каждого подпроцесса в среднем 10 подпроцессов. У подпроцессов есть задачи. Все задачи друг с другом связаны тем или иным образом. Отобразить эти сотни взаимосвязей в таблице - это 30-50 страниц - одна только таблица.

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

Сделал всё на скорую руку. И честно говоря, тяп-ляп за вторую неделю. Качественной осталась только первая часть, которую я делал неделю. Все остальные четыре части вышли, прямо скажу, неважно как...

Вышло под 300 страниц просто жуткого текста. Так как делалось на скорую руку, было допущено ужасное количество ошибок. Честно скажу, использовал несколько прошлогодних курсовых работ и неумело их объединил. Преподаватель не идиот и сразу же заметил большое количество нестыковок между разными частями курсового проекта. Я надеялся сдать, но меня развернули на переделку. В общем-то, это было справедливо.

Потом ещё в течение примерно трёх недель я представил ещё 3 распечатанные версии. И к моменту окончательной сдачи получил свою четвёрку и, в довесок, ещё сам уже знал обо всех изъянах, которых ещё хватило бы на неделю-другую.

Так я понял, после большого количества бессоных ночей, что есть задачи, которые в принципе невозможно решить за неделю наскоком. Я провозился с курсовиком почти месяц. И вышло откровенно плохо. Хотя и четвёрка находится в моей зачётке. Мне повезло, что преподаватель был излишне строг и не закрыла глаза на недочёты. Эта излишняя строгость достаточно приближена к реальным условиям. Я извлёк из этого курсовика ценный урок для себя.

Это был пример, когда задача явно не терпела моего подхода к делу. Ещё один пример, я как-то работал целые полгода над проектом - графическим движком. Вкратце, отмечу, что эта технология позволяла программисту делать трёхмерные программы (игры, софт) достаточно быстро (от часа и более).

Над этим проектом я работал практически ежедневно, но по чуть-чуть. С 1 сентября 2004 по 1 марта 2005. Не смотря на ремонт дома. Потом эта разработка была заморожена. Но благодаря ей я получил:

- Лауреата на школьной конференции в 11 классе;
- 1 место на городском конкурсе по программированию среди школьников и премию с поездкой в на республиканский конкурс в санаторий «Крутушка» - бывший пионерский лагерь;
- 1 место в конференции, которую проводил филиал КГУ в 2005 году (название конференции к своему стыду я уже забыл);
- Лауреата республиканского конкурса по программированию;
- 1 место на городском конкурсе по программировани среди студентов ВУЗов и колледжей;
- Отправил работу на стипендию в АкБарс Банк в сфере информатики. Пока не знаю понравится ли им эта работа или нет.

Кроме того использовал эту разработку в довольно большом количестве проектов.
- Презентационный компант-диск КамПИ 2006;
- Презентационный компакт-диск автомеханического факультета ИНЭКА 2006, 2007;
- Геоинформационная система САФ 1.0, 2.0, 3.0;
- Кроме того разработка использовалась при написании нескольких простых игр.

Отдача от этого проекта для меня оказалась намного более сильной, чем 6 месяцев работы, которые я на этот проект потратил. Помимо того, что я проработал технологию программирования графики, я стал профессиональным программистом ещё до окончания школы, получил впоследствии очень много бонусов в виде предложений работы и участия в различных мероприятиях.

На дворе вторая половина 2009 года. И только сейчас этот проект понемногу выходит из регулярного использования. Жизненный цикл проект оказался по-настоящему долгоиграющим.

Из статьи можно сделать вывод: для небольших проектов метод интенсивной и быстрой разработки подходит отлично. А вот крупные проекты лучше собирать по крупицам. Это всего лишь моё мнение, основанное на позитивном и негативном опыте. Моё мнение не претендует на истину в последней инстанции, но заслуживает того, чтобы на него обратили внимание.