От идеи до реализации. Часть третья — создаем ТЗ (техническое задание)

Данилевский Кирилл

Прошу прощения у читателей за долгий перерыв. Сейчас работаю на крупном проекте, времени ни на что не хватает. Итак, пишу продолжение к циклу статей «От идеи до реализации.» Вот предыдущая статья: «От идеи до реализации. Часть вторая — рождение идеи»

Сегодня я хочу немного поговорить о том, как сократить свой путь от голой идеи до получения инвестиций. Здесь есть два важных момента. Для себя нужно решить, кто будет выступать инвестором. Если вы в состоянии сами себя финансировать, то это очень хорошо. Но если у вас с финансами проблемы, то без внешнего привлечения денег вам не обойтись.

Но для того, чтобы заинтересовать инвестора, вам необходимо предоставить ему достаточно подробные документы. Так как разговор с объяснением, грубо говоря, на пальцах, не дает инвестору возможность увидеть картину целиком. А следовательно и о деньгах тоже не может быть никакой речи.

И наша главная задача — это подготовить такие документы, которые помогут вам получить финансирование и смогут вам самому прояснить картину с будущим вашего проекта.

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

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

И в какой-то момент приходит понимание того, что спрос на проведение опытов не так велик, лаборатория ограничена своей пропускной способностью, получать заказы из разных стран достаточно сложно, каждый раз необходимо проводить большое количество переговоров, заключать договора и т.д. Основная мысль проблемы в том, что не получается прыгнуть выше головы. А те «прыжки» что есть, достаточно сложные, не мобильные и дорогостоящие.

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

Идея интересная, уже более-менее сформированная. Начинаются поиски инвестора, который готов вложить в эту идею финансы. Но первый вопрос — сколько нужно вложить денег в этот проект? И ответа на этот вопрос нет. И второй момент — это если инвестор не разбирается в физике, то он вообще не поймет того, что ему будут пытаться объяснить. А вкладывать деньги в то, чего инвестор даже примерно понять не может, он уж точно не будет.

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

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

Теперь переключимся на работу системного аналитика. Есть задача — разобраться в принципе работы бизнеса, создать документацию, которая сможет оценить время, необходимое на разработку программного обеспечения. Оценка времени, как правило, может быть либо грубой, либо более-менее детальной. В первом случае не будет создано подробное техническое задание, а будет только создана модель архитектуры. Во втором случае будет разработано детальное ТЗ, которое уже будет готово для старта процесса разработки.

Естественно, зная количество времени, которое потребуется для разработки, зная платформу, на базе которой будет производится разработка, уже можно более-менее рассчитать сумму вложений для проекта. А когда есть цифра, которая рассчитана и обоснована, то уже есть о чем говорить с инвестором.

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

СОЗДАЕМ ТЗ ДЛЯ ПРОЕКТА

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

1. Очень подробно описывается идея проекта. Аргументируется эта идея. Почему она должна сработать. Какие конкуренты уже присутствуют на рынке. Какая у них доля рынка. Насыщен ли данный рынок или испытывает голодание на подобное решение.

2. Каким образом планируется монетизация проекта. Этот пункт также можно связать и с выбором платформы. Это будет онлайн приложение или десктоп версия. Анализ того, какая версия лучше, более гибкая и масштабируемая. Каким образом будет происходить оплата за приложение. Например, платная программа с индивидуальным ключом. Онлайн доступ к программе (сайту) на определенное время (лимитированный доступ) и т.д. Это важный момент и его нужно продумывать сразу. Так как ошибка в этом вопросе, может в будущем поставить крест на всем проекте.

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

4. Нужно продумать, каким образом будут хранится данные в базе данных. Продумать таблицы для данных и их связи. Если проект будет большим, сразу нужно думать не об одной базе, а о большем их количестве, где и как их размещать (на разных серверах). И как они будут связаны в едином проекте. Часто сталкиваюсь с такой картиной, что базы раздуты до терабайтов, и уже сделать с ними что-либо просто нереально.

5. Если предполагается, что будет много разных проектов на базе одной платформы, то нужно продумать, как им лучше работать. Не стоит пихать весь функционал в один гигантский сайт. Лучше разнести все по разным серверам. Но тогда придется делать промежуточный сервер, где будет происходить авторизация и т.д.

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

7. После того, как были изучены тонны документов по физике, понятна суть проекта и на основании этого создана модель базы данных, то самое время подумать над тем, как эти данные будут записываться в базу, и как они будут получаться из базы. А значит, требуется продумывать интерфейсы, через которые будут заноситься данные. Речь сейчас идет именно о статистических данных, на основании которых будет коррелироваться результат расчетов.

8. Нужно продумать независимую модульную систему для формул, которые будут производить расчет. Формулы должны быть не связаны друг с другом и полностью независимы. А уже в самом проекте, когда и где это необходимо, то обращаться к формуле, отдавая ей данные и получая от нее результат. Это вам позволит, в случае каких-либо изменений, сделать изменения только в маленьком и отдельном модуле. При этом ничто другое не пострадает и не повлияет на работу самого проекта.

9. Для подобных сложных проектов просто необходима система самодиагностики. Она должна быть разбита на две части. Первая — это диагностика базы данных, на корректность данных. Ведь речь идет о сложных математических расчетах. А значит, даже маленькая ошибка (например, некий коэффициент в базе равен не 0.5, а 0.6) может привести к фатальным последствиям. Для этого нужно иметь некие эталонные данные, которые будут сверятся с реальными в базе. И если реальные данные вышли за предел допустимого порога, то администратор должен это знать и сам принять решение, что с этим делать. Тоже касается и формул вместе с входными параметрами. Параметры должны быть только в рамках допустимой погрешности.

10. Пользовательский интерфейс. Этот вопрос тоже очень важен. Система должна быть интуитивно понятна, легка в использовании и очевидна.

11. Система защиты данных и общая взломоустойчивость. Об этом моменте тоже не стоит забывать. Если какой-то хакер сможет обрушить ваш сервер или украсть ваши данные, то не о каком бизнесе тогда вести речь будет нельзя.

12. Автоматизированная система оплаты и доступа к системе. Этот процесс должен быть полностью автоматизирован. Должны строиться понятные и подробные отчеты. Нужна система анализа данных по платежам (что-то типа финансового отчета). Автоматические уведомления пользователей и администраторов.

13. Система подробного анализа пользователей. Производимых ими расчетов и действий в системе. Это поможет находить узкие места в проекте и улучшать качество вашего приложения.

14. Лицензирование. Защита авторских прав. Ну тут без комментариев. Если вы хотите получить серьезного корпоративного клиента, то вы должны позаботиться о том, что ваше программное решение имеет международную лицензию, которой можно доверять.

Конечно, это не все пункты. Но для понимания процесса, этого вполне достаточно. Каждый из этих пунктов дробится на более мелкие задачи. Те в свою очередь также дробятся. В итоге получается огромное дерево процессов (листики на дереве). И каждый мелкий процесс (задачу) уже можно достаточно точно просчитать по временным затратам.

Также к этому времени нужно прибавлять затраты на производственные мощности, на рекламу и раскрутку, и еще множество разных факторов, которые невозможно сразу просчитать, но которые обязательно возникнут.

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

Естественно, то о чем я сказал выше, касается сугубо профессионального подхода. Если делать это на тяп-ляп, типа «и так сойдет», то получим примерную картину того, почему большая половина интернета представляет из себя помойку, а не технологический шедевр.

Всем спасибо и до новой встречи.

ссылка на оригинал статьи https://geektimes.ru/post/275068/