Методология. Часть 1
Если кратко описывать разнообразие подходов к разработке или созданию чего угодно, то можно сказать, что выбор какого-либо из подходов — это творчество.
Создание логотипа, дизайна, бренда — это исключительно творческая работа, и тут нет никаких технически выверенных формул. Математик не разработает логотип лучше художника, — по этой причине, кстати, нейронные сети не пользуются спросом при создании бренда. То же самое можно сказать и про разработку продукта: самый важный этап при создании — это логика.
Нет никакого смысла тратить полезные часы программистов и дизайнеров на рисование брошюр, рекомендаций, красивых пояснительных журналов, пока не пишется сам код, который можно запустить, «пощупать» на устройстве. Но пренебрежение логическим проектированием обязательно вызовет сбой в работе. Причем сбой возникнет неожиданно перед самым завершением работы, на этапе пуско-наладочных работ.
По этой причине мы выделили такой важный пункт работы как инфологическая модель. Он не основан на технических инструментах, не требует навыков программирования. На этапе работы с инфологической моделью требуется максимальная вовлеченность всей проектной группы.
Простыми словами, инфологическая модель — описание предметной области. Описание, которое наглядно отражает то, с чем вам предстоит иметь дело. В нашем случае — это создание программы.
Хорошо рисуете? От этого вообще-то зависит ваш проект!
Методология «ProT» основана на работе с инфологической моделью, прототипированием и программными модулями. Особенности прототипирования и модульной разработки я опишу в следующих статьях. В отличие от самого прототипа, где от расположения кнопки будет зависеть удобство приложения или сайта, логическая модель включает в себя схематическое отображение. Все относящиеся к делу вопросы: кто, где, куда, зачем (и еще 1000 вопросов и ролей) будут отображены в схеме вашей модели. Сама модель рисуется даже в вашем ежедневнике. И тут, скорее, от того, как вы хорошо и точно ее нарисуете, будет зависеть конечный результат. По опыту, технический персонал легче реализовывает наглядно описанную схему, чем абстрактные текстовые задания. Цветочный магазин имеет 3 торговые точки в городе N. Для того, чтобы экономить на закупке цветов собственник магазина ежедневно обзванивает поставщиков и узнает актуальные цены. Это занимает час-два его личного времени. И вот он решает уйти от этой рутинной работы. Тогда владелец заказывает программу, в которой все поставщики будут сами записывать актуальные цены, и для этого им не нужно будет заходить в таблицы, отправлять цифры в чат. Просто каждый день представитель прикрепляет прайс в форму на сайте. Удобно? Удобно! Делаем! НО Специалист, разработавший эту программу, может поставить владельца магазина в тупик. Есть сайт. Есть таблица с поставщиками. Есть таблица с цветами, и даже цифры готовы меняться в зависимости от данных поставщиков. Это все? Если очень занятая и вечно хмурая женщина — бухгалтер / секретарь / владелец со стороны поставщика забудет про владельца магазина, то никакие цифры он не получит. Придется снова звонить... Если владелец пропустит обновление цен у одного поставщика, то не сможет сэкономить на закупке, так как сделает заказ у другого. Резонный вопрос: зачем тогда писалась программа? Все это демонстрирует отсутствие логического проектирования в самом начале работы. При условии, что программа написана безупречно, она не приносит никакой пользы, и даже наоборот — путает и расстраивает. Технический специалист не является владельцем цветочного магазина, чтобы знать эти тонкости. Но и владелец магазина далек от программирования и просто не сказал об этом, потому что «думал, это само собой разумеется!». Я читал множество шуток в интернете про то, что заказчики чаще всего не знают, чего они хотят. Например, как на фото ниже :) Зачастую идея не воплощена не по причине провальной работы или из-за «пения птичек», а лишь потому, что идея не была правильно сформулирована. Мы помогаем нашим клиентам сформулировать их идею, создать первый план их стартапа, даже подобрать программные инструменты для реализации на консультациях. Но если компания-клиент уже сформулировали свои пожелания, значит, работа над логикой уже началась. Значит над последовательностью и описанием подумали заранее. На самом первом звонке с ответственным представителем я задаю вопрос: «Имеется ли у вас техническое описание?» В ответ на мой вопрос я получаю документ с самым простым описанием предметной области. Бинго! Стоит мне чуть больше вопросов задать ответственному представителю, занести его ответы в документ, и я уже имею хорошую заготовку логической модели. Что дальше? Править, дополнять и «раскладывать по полочкам». Дальше идет голое творчество, — то, с чего я начал эту статью. Больше о методологии нашей работы, проектах и новостях мира ИТ читайте в официальной группе Program Tactics и нашем Telegram — канале
Пример
Разработка логики начинается до того, как вы о ней подумали
