1. Отсутствие ТЗ.

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

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

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

Не экономьте время и деньги на составлении ТЗ. Без четкой карты ваш корабль будет еще долго бороздить моря в лучшем случае. В худшем он просто не доплывет до намеченного места.

2. Ведение задач в таск трекере и постоянная их актуализация.

Не забывайте, разработчики это отдельные головы и руки. Единый центр управления обязан существовать, иначе траектория вашего проекта будет размыта и непредсказуема. Задачи должны быть оформлены в документах доступных для всей команды (лучше всего использовать системы управления задачами Jira, Trello, Assana и т д), разбиты на спринты (1–4 недели, в зависимости от проекта) и всегда поддерживаться в актуальном состоянии, иначе вы не будете видеть прогресса по вашему проекту, а вся команда будет двигаться как электроны по орбиталям атомов.

3. Отсутствие архитектуры в проекте.

Для всей команды, начало проекта считается от составления и согласования ТЗ. Однако отдел разработки берет на себя самые сложные задачи во всей истории создания вашего продукта. Можно сказать это 80% от всей работы, которую придется проделать. Столь объемная и технически сложная часть вашего продукта, не может быть без своего внутреннего регламента, который стоит продумать прежде чем начать всю работу. Поэтому если не тратить время на продумывание архитектуры в проекте, о его масштабировании можно забыть, а новые разработчики будут отказываться от поддержания его, или очень долго входить в ваш проект. В общем, опять возвращаемся к тому что скупой платит дважды.

4. Отсутствие шифрования.

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

Безусловно, ответственность за утечку данных и кражу денежных средств будут нести не разработчики, которые уложились в свои сроки, а владелец данного сервиса — собственно говоря вы сами.

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

5. Отсутствие UnitTest.

Как известно, никто не любит платить за то, что не видит своими глазами, особенно когда ценник увеличивается в 1,5 – 2 раза. В связи с этим многие команды исключают, такой важный пункт из сметы, как unit-тесты.

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

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

6. Непродуманное использование готовых решений.

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

Такие риски всегда кажутся маловероятными и многие идут на них, даже не думая о том, что с ними такое может приключиться.

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

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