Pull to refresh

Итеративный подход к решению инженерных задач

Reading time 5 min
Views 8.8K
Ну вот, дожил и я до того дня, когда меня потянуло написать в этот блог.
Доброго времени суток, хабрачеловек!

Так уж сложилось, что многие из обитающих на славном Хабре жителей так или иначе связаны с разработкой. Под разработкой я здесь подразумеваю чуть более широкий и абстрактный термин, чем написание программ. Разработка — это прежде всего созидательные действия, творческий процесс. На входе этого процесса — мысль, идея, а на выходе — осязаемый продукт, детище разработчика. Конечным продуктом может быть все, что угодно: сайт, дизайн, программа, хитроумный девайс, умный дом и пр.

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


Представим себе стандартную для инженера ситуацию — в нашем мозгу появилась идея. Родилась сама, была подкинута сочувствующими товарищами или инъецирована заказчиком очередного бредового проекта — механизм ее появления в мозгу не важен. Предположим, что идея звучит так: «Счастья всем, даром! И пусть никто не уйдет обиженным!» (с). Обычно, из формулировки идеи очевидно, ЧТО мы хотим получить в итоге. Зато не очевидно КАК мы хотим этого добиться. Вот тут-то перед нами и появляется задача. Задача реализации идеи.

Задачи нужно решать. Так учили в школе. Но каким образом взяться за эту гладкую без единой зацепки особу? Мы чувствуем смятение, вызванное незнанием, что конкретно необходимо сделать для решения поставленной задачи. Итак,
предлагаю следующий алгоритм. Сразу обмолвлюсь, что не претендую здесь на оригинальность, возможно подобный поход уже был описан где-то еще, но я его раньше не встречал.


Отправным пунктом будем считать формулировку задачи («раздобыть где-нибудь счастья на всех»). Будем считать, что мы работаем над проектом по его добыче. Что же нужно первым делом сделать для его выполнения? Для начала необходимо сформулировать то, как проект на выходе для себя представляет заказчик (в данном конкретном примере — все человечество, в общем же случае это может быть работодатель или даже мы сами). То есть выявить внешние требования к проекту. В нашем случае все просто — каждый житель земного шара должен стать счастливым. В общем же случае результатом данного шага может быть пара страниц текста, содержащая самые общие сведения о конечной цели. В случае, когда результат трудно описать общими фразами, можно прибегнуть к описанию желаемого через способ его употребления конечными пользователями (пользователи должны видеть две кнопки «еще счастья» и «поделиться счастьем с соседями». При нажатии на кнопку 1… и т.д.).

Так, уже лучше, так как половина дела сделана — мы приступили к работе! Что дальше? Далее необходимо изучить предметную область, в которой придется работать. Цель данного этапа — познакомиться или обновить в памяти способы работы с сущностями данной предметной области, научиться разговаривать и думать в терминах решаемой задачи. Конечным результатом второго этапа является преобразование общих требований, полученных на шаге 1, в четкие подзадачи по достижению этих требований. В нашем случае это может выглядеть примерно так: «Счастье… Что же это такое и с чем его едят? Счастье — это состояние души, достигаемое при благоприятной совокупности внешних и внутренних факторов, влияющих на конкретного индивида. Детей счастливыми делает мороженое, влюбленных — поцелуи, политиков — власть, сисадминов — резервное копирование. Следовательно, необходимо следующее: построить заводы по производству власти, наделить детей мороженным...»

Отлично, теперь мы точно знаем, что нужно сделать для выполнения проекта. Но что, если проект рискует затянуться на длительное время? Или если мы работаем над ним целой командой? Третьим шагом необходимо навести порядок в том ворохе информации, что мы насобирали на предыдущем этапе и специфицировать (да-да, записать!) сформулированные подзадачи. Итак, производим максимальную декомпозицию подзадач и выделяем последовательности действий по решению минимальных задач, которые уже не возможно разбить на составляющие (что-то вроде: "… нам нужны заводы по производству счастья. Для этого на нужны рабочие. Рабочих нужно обучить. Значит поступаем так: берем 20 перспективных учащихся старших классов и ..."). Специфицирование подзадач — работа серьезная, трудная и отчасти нудная. Но она имеет в себе сразу несколько плюсов — во-первых, это неявное проектирование. Часто бывает так, что когда пишешь, что ты собираешься сделать (а не сразу бросаешься в код с клавиатурой наперевес), вскрываются некоторые тонкости, которые были упущены в первом приближении, принимаются полезные архитектурные решения и вносятся упрощающие дальнейшую разработку корректировки. А от некоторых задач вообще приходится отказаться. =) Во-вторых, она позволяет точнее оценить трудозатраты на реализацию задуманного, потому что чем меньший объем работы оценивается, тем больше вероятность в дальнейшем назвать правильные сроки на его реализацию. И в-третьих, когда есть утвержденные спецификации, проще избежать соблазна бесконечно улучшать существующие фичи и дописывать новые, оттягивая и оттягивая момент запуска проекта. На самом деле трудно заранее определить, что именно будет нужно пользователям и какая возможность в дальнейшем определит популярность продукта. Сначала нужно стартануть с некоторым минимальным набором, обеспечивающим жизнеспособность, а уже потом дописывать новые функции, исходя из реальных потребностей пользователей. Результатом данного шага является документ, содержащий описание подзадач и способы их решения.

Наконец-то мы как никогда близки к самому любимому — к собственно реализации. Но не спешим — сначала необходимо оценить время, которое потребуется на выполнение каждой подзадачи в отдельности. К этому моменту мы уже максимально упростили себе жизнь, написав спецификации, осталось лишь проставить цифры («Сделать счастливыми жителей Австралии — 48 часов, Албании — 32 часа, Америки — 72 часа...»). Основная цель данного этапа — постараться загнать каждую из подзадач в некоторые временные рамки. На самом деле, несмотря на существование огромного числа методик планирования и оценки трудозатрат, данный этап является весьма абстрагированным от действительности и рядом с цифрами правильнее было бы проставлять не часы, а попугаев, но некоторая аппроксимация все же будет получена. И это приближение будет все точнее при каждой последующей итерации (о которых мы пока ни слова не сказали). Результатграфики работ над проектом.

Ну вот и настал сладостный момент, когда нужно поработать руками. Смело хватаемся за клавиатуры, молотки, паяльники и прочие орудия труда и претворяем задуманное и описанное в жизнь. Мы на этапе реализации. Результатом будет являться код, микросхема, девайс, что угодно, но — лишь пробная версия. Вот тут появляется развилка — удовлетворяет ли наше детище тому, о чем мы так давно говорили на этапе 1? Если да — смело подводим итоги и отправляем его во взрослую жизнь. Но с первой попытки ответить «да» на этот вопрос удается очень редко. Скорее всего по прошествии всех вышеописанных этапов мы лишь осознаем, что теперь лучше понимаем, чего же мы хотели добиться в результате, что нужно делать, чтобы реализовать идею и добиться цели. Что же мы имеем в качестве настоящего результата этапа реализации? Более четкие, осознанные, опробованные на практике, родившиеся в боях требования! Ну что, уже догадались? Смело на этап 1! Первая итерация прошла успешно, поздравляю, коллега!

Заключение

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

UPD: Пользователь iasonov предложил смотреть в направлении ТРИЗ:: АРИЗ, в котором имеется вот такая интересная схема. Все дружно топаем и изучаем.
Tags:
Hubs:
+22
Comments 23
Comments Comments 23

Articles