Всем привет!

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

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

Давайте подробнее разберем каждую область, и я объясню, что имею в виду.

Исследование пользователей

Важность исследования пользователей сложно переоценить. Вы должны знать, кто будет пользоваться вашим продуктом. Можете ли вы описать типичных пользователей и их путь в продукте? Можете ли связать результаты работы с потребностями пользователей? Если хотя бы на один из этих вопросов вы ответили «нет», стоит пересмотреть свой подход к разработке продукта.

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

API-контракты

Вторая важная область — API-контракты. Для начала, что такое API? Если совсем просто, это способ взаимодействия программ друг с другом. Думаю, большинство читателей хорошо знакомы с IT, поэтому подробно объяснять не буду. Но если хочется понятного разбора, вот замечательное видео, где эта идея объясняется очень хорошо.

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

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

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

Архитектура

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

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

Моделирование данных

У Никлауса Вирта, одного из пионеров компьютерных наук, есть известная книга «Алгоритмы + структуры данных = программы». Модель данных, современное воплощение «структур данных», — это почти половина вашей информационной системы. На ранних этапах разработки, когда данные «нужно просто куда-нибудь сохранить», ее важность легко недооценить. Но в какой-то момент появляются задачи, которые сильно зависят от устройства данных: аудит, соблюдение нормативных требований, сложная отчетность и так далее. Ваша модель данных изначально это поддерживает? Если нет, готовьтесь к сложному и дорогому рефакторингу с высоким риском ошибок. Поэтому я считаю, что на этапе планирования всегда стоит потратить время на тщательную проработку модели данных, чтобы избежать проблем в будущем.

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

У вас другое мнение? Оставляйте комментарий или пишите мне напрямую — я всегда рад хорошему разговору!

Продолжение следует!