В прошлой публикации мы научились убирать из нашего продукта все ненужное. Сегодня разберемся со сроками реализации MVP. Некоторые считают, что приемлемый срок реализации MVP — до 6 месяцев, но мой опыт реализации стартапов показывает, что оптимально — до 4 месяцев, в идеале до 3. А тестирование гипотезы (например, с помощью трафика на лендинг) — до 1,5 месяцев. Почему так? Все просто. В среднем после 3-4 месяцев команда начинает выгорать из-за отсутствия каких-либо результатов. Отмечу, что даже выпуск первой, пусть и сырой версии MVP — результат, который мотивирует команду. Вернемся к нашему трекеру решений, который появился в прошлой публикации. Начнем анализировать наши функции. Первая — интернет-эквайринг для списания денег за пропущенную привычку. Ключевой вопрос для анализа: «Как реализовать функцию за минимальный срок?». Для этого нам нужно выбрать эквайринг, у которого:— самое простое с точки зрения интеграции SDK;— быстрое юридическое оформление. Среди выбранных провайдеров выбираем того, у кого:— минимальные комиссии;— больше возможностей для приема платежей из разных источников. Логика простая — в первое время нету смысла ожидать большого наплыва подписчиков, поэтому потери прибыли на комиссиях эквайринга — минимальны, а вот оплачивать дополнительное время разработчика выйдет гораздо дороже, чем транзакционные издержки. Пройдите подобным образом по каждой функции MVP, чтобы максимально сократить сроки реализации.

dbfb984a5d2c25c53b522d7652c958d5_post.jpg

Разберемся со сроками реализации MVP.

процессразработки

Сокращаем срок реализации MVP

Представим, что мы хотим создать эффективный трекер привычек. После всестороннего изучения конкурентов и других маркетинговых изысканий, формулировки миссии и идеи, мы пришли к нашей финальной концепции: «iOS &amp; Android мобильное приложение, которое позволит вести базу привычек и будет списывать 1000 рублей за каждый второй пропуск привычки». Концепция есть, теперь пора подумать о том, как должно выглядеть MVP. MVP — это минимальный жизнеспособный продукт. Если детализировать, то MVP — это такой продукт, который обладает минимальной реализацией ключевого функционала, которая делает продукт пригодным для использования и, в том числе, для его продажи. По опыту работы с предпринимателями, стартаперами и с собственными проектами, первая концепция MVP будет содержать следующий функционал: 1. Добавление / удаление / редактирование привычек из любого места в приложении;2. Виджеты, чтобы видеть сколько привычек осталось выполнить;3. Сотни различных напоминаний о времени привычке, о промоакции, о дне рождении папы основателя проекта и т.д.4. Подключить 100 платежных систем, чтобы даже койсанские народы смогли оплатить пропущенную привычку.5. Статистика с обширной детализацией. И еще 100500 фишек, которые кажутся неотъемлемой частью продукта. И тут пора порефлексировать. Ключевой вопрос нашей рефлексии: «А зачем мне эта функция?». Прежде чем задавать этот вопрос, надо выявить, а что является самым главным в продукте и какие функции, необходимы для реализации самого главного. Этот процесс выглядит так: 1. Какой ключевой функционал в моем продукте, который является точкой отличия от конкурентов? В случае нашего трекера решений — это списание 1000 руб. за просроченную привычку. Теперь наша основная задача сделать самый минимальный функционал для его работы. 2. Что нужно, чтобы ключевой функционал работал?— Интернет-эквайринг — сердце ключевого функционала.— Возможность добавлять привычки, чтобы было за что списывать деньги.— Уведомление о необходимости выполнить привычку, чтобы не выглядеть грабителями.— Функции, необходимые согласно гайдлайнам сторов. Например, удаление аккаунта.Отлично! Мы определились с функциями, которые жизненно необходимы для нашего трекера решений. 3. У нас получилось все слаженно, но чаще после пункта 2 требуется несколько раз пробежаться по функциям с вопросом: «А зачем мне эта функция?». И если есть, хотя бы малейший намек на ответ «незачем», то эту функцию нужно ликвидировать, либо сократить до чего-то более простого. Мы определились c тем минимумом, который нам необходим для реализации. Но есть еще одна компонента, которую нужно проработать — срок реализации MVP. О ней мы поговорим в следующей публикации.

334be416923c2351448e8b2ddcee8041_1.jpg

В этой статье вы узнаете, на примере, о том, как перейти от концепции к MVP без лишних усложнений в функционале продукта

От концепции к MVP

В этой публикации мы поговорим о том, чем идея отличается от концепции. Сделаем это на примере конкретной цели. Представим, что наша цель это в течение года сделать так, чтобы доставка продуктов занимала не более 15 минут с момента поступления заказа. Так вот, идея — это абстрактное представление замысла, намерения или мысленного образа чего-либо. Еще можно сказать, что идея — это абстрактные пути достижения цели. Рассмотрим примеры идей для нашей цели: <ol><li>Оцифровать процесс доставки товаров.</li><li>Роботизировать процесс сбора товаров в дарксторе.</li><li>Вовлечь в доставку таксистов.</li></ol> Наиболее подходящий вопрос для постановки идеи: что нужно сделать для достижения цели? Концепция же — это конкретизированная идея. Рассмотрим примеры концепций для нашей цели: <ol><li>Разработать удобное мобильное приложение для пользователя и службы доставки, интегрированное с внутренней системой автоматизации.</li><li>Интегрировать технологию компании N, которая поставляет аппаратно-программный комплекс для автоматизации дарксторов.</li><li>Начислять таксистам бонусы в размере 100 рублей за каждый принятый заказа на доставку продуктов.</li></ol> Наиболее подходящий вопрос для постановки концепции: как можно реализовать эту идею? Наличие концепции — это хороший задел, который представляет из себя вполне конкретное виденье продукта. Поиск идеи и концепции — творческий процесс, которой хорошо проводить в режиме мозгового штурма с использованием открытых вопросов. Вовлекайте в этот процесс, если такое возможно, и тех, кто менее заинтересован в конечном результате, либо никак не связан с ним.

30731c882bb66aaba6ec629dd3b294b0_1.jpg

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

От идеи к концепции

В этой статье разберемся, что такое аутсорс- и аутстафф-разработка. Есть еще третий вариант - формирование ИТ-отдела, но он тянет на отдельный цикл публикаций, поэтому эту тему я опущу в этой статье. Аутсорсинг - это когда вы нанимаете ИТ-команду, -компанию или фрилансера для решения вашей ИТ-задачи, например для разработки мобильного приложения, призванного оптимизировать процесс оптовых закупок вашего предприятия. Аутстаффинг - это когда ИТ-команда или -компания предоставляет вам своего сотрудника(-ов) под ваше управление, но без трудоустройства в штат вашего предприятия. <h2>Основные плюсы и минусы аутсорсинга</h2> Плюсы:1. Комплексный подход к решению вашей задачи. И клиентское приложение создадут, и серверное, еще и продвинут.2. Не нужно контролировать процессы. С вас задачи, с исполнителя решение, все что между - не ваша головная боль, но на подготовительном этапе, все равно, придется активно принимать участие.3. Если кто-то уйдет из команды разработки, вам не придётся искать ему замену, это ложится на плечи аутсорс-компании/-команды. Минусы:1. Внимание распределяется между всеми клиентами. Если у компании 10 клиентов и один аккаунт менеджер, то коммуникация будет рассеянной. Согласитесь, тяжело распределять внимание сразу на 10-ых клиентов.2. Непонятно, как формируется цена и что в нее закладывается. Некоторые исполнители неимоверно раздувают свой чек, а некоторые и вовсе не могут трезво оценить стоимость своих услуг.3. Нельзя активно влиять на процесс разработки. Чаще всего, аутсорс-исполнитель выступает против того, чтобы вы встревали в его бизнес процессы, поэтому вам остается получать отчеты о проделанной работе и терпеливо ждать результата. <h2>Основные плюсы и минусы аутстаффинга</h2> Плюсы:1. Контроль над деятельностью исполнителя. Человек поступает в ваше полное распоряжение. Весь процесс от постановки задачи и до контроля над исполнением возлагается на вас.2. Не нужно заботиться об отчислениях в различные фонды. Снимает с вас бухгалтерскую волокиту. Вы выплачиваете гонорар аутстафф-сотрудника компании, которая его предоставила.3. Не нужно усердно проверять компетенции сотрудника. Гарантом, в данном случае, выступает компания, которая предоставляет его. Минусы:1. Решение ограниченного количества задач. Вы берете человека для решения конкретной задачи, например для работы над разделом мобильного приложения. Он не будет заниматься ничем другим, кроме этого.2. Сложность интеграции в рабочий процесс вашего бизнеса. Нужно заложить время на адаптацию и обучение использованию внутренних систем предприятия. Есть еще один общий минус - чаще всего компании и аутстафф-работники трудятся ради денег, а не ради идеи вашего продукта или бизнеса, поэтому мотивация и вовлеченность может быть низкой. <h2>В каких случаях подойдет аутсорсинг, а в каких аутстаффинг?</h2> Аутсорсинг оптимален в большинстве случаев, особенно, когда вы начинаете разработку с нуля и у вас нету собственного ИТ-отдела. Аутстаффинг больше подходит для случаев, когда у вас уже есть свой ИТ-отдел и вы хотите его временно расширить для решения какой-то задачи.<h2> </h2><h2>Заключение</h2> Прежде чем выбрать формат исполнителя для вашего ИТ-решения, важно рационально оценить ваши цели. Например, если вы открываете ИТ-компанию полного цикла, то вам подойдет создание ИТ-отдела, если вам нужно создать MVP проекта, то подойдет аутсорс-разработка, а если у вас уже есть заряженный ИТ-отдел или есть продукт, в котором вы четко знаете какой-пул задач нужно выполнить, то подойдет аутстаффинг.

68fa0cafa8470e2c299ad182b721b1c1_2.jpg

В этой статье разберемся, что такое аутсорс- и аутстафф-разработка.

В чем отличие аутсорсинга разработки от аутстаффинга ИТ-сотрудника для разработки?

Сегодня большинство компаний сталкивается с ИТ-разработкой. Цели могут быть разные: создание стартапа, автоматизация бизнес-процесса и так далее. Есть несколько основных путей для получения ИТ-решения — заказать аутсорс-разработку, сформировать ИТ-отдел внутри компании, отдать разработку фрилансеру, нанять аутстафф-исполнителя. Не имеет значения, какой путь выберите вы. Важно, чтобы вы были осведомлены о том, как устроен процесс создания ИТ-решения и какие подводные камни возникают на нем. Это убережет от лишних трат и позволит получить желаемый продукт. В разработке выделяю следующие основные разделы: 1. Формулировка концепции. Когда у вас зарождается идея какого-то продукта, необходимо преобразовать ее от уровня идеи до уровня концепции. Мы научимся формулировать концепцию и убирать из нее все лишнее. На выходе мы получим MVP, над которым и будем работать. 2. Подготовка. От этого этапа зависит, получите вы продукт или потеряете деньги. Формулировка задачи, определение бюджета, проектирование, выбор подрядчика — это лишь небольшая часть вопросов, которые нам предстоит решить. 3. Разработка. На этом этапе создается дизайн продукта, разрабатывается техническая часть. Важно правильно выстроить коммуникацию с исполнителем, научиться определять качество оказываемых услуг и еще много чего интересного. 4. Тестирование. «7 раз протестируй, 1 раз запусти в продакшн». Некоторые компании, в том числе и ИТ, пренебрегают этим важным этапом, хотя он значительно сокращает финансовые потери при неудачном запуске. Процессы этого этапа пересекаются с процессом разработки, но я сознательно выношу его в отдельный раздел. 5. Запуск и постобслуживание. Выпуск MVP — это лишь верхушка айсберга. Нам нужно собрать и проанализировать метрики MVP, сформировать дорожную карту по проекту, понять, как убережем продукт от преждевременного устаревания.

22e2985e3053ea23c7690505d612a085_1.jpg

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


Введение в разработку

В процессе разработки, неизбежно, возникают повторяющиеся архитектурные решения. Есть два пути работы с такими решениями:<ol><li>Принять и дублировать их в коде. Это сделает ваш код нечитаемым, что далеко не самое страшное. Представьте, что у вас есть сто файлов с кодом, в которые вы скопировали какой-то повторяющийся код. Оказалось, что в этом куске, скопированного кода была ошибка. Теперь вам предстоит внести правки в каждый из ста файлов - вот это страшно.</li><li>Использовать один из шаблонов проектирования. Это структурирует код и поможет избавиться от избыточности в архитектуре.</li></ol> Чтобы не выдумывать определение, я процитирую его из Википедии:<blockquote>Шаблон проектирования или паттерн (англ. design pattern) в разработке программного обеспечения — повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.</blockquote> Многие паттерны проектирования опираются на принципы ООП, поэтому я напомню эти принципы. Снова обратимся к Вики:<blockquote>Объектно-ориентированное программирование — методология программирования, основанная на представлении программы в виде совокупности взаимодействующих объектов, каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования.</blockquote> Выделяют следующие принципы ООП:<ol><li>Абстракция. Мы класс людей и у нас есть ногти, это общее важное свойство. У кого-то ногти накрашены, а у кого-то нет - это неважное свойство, его опускают в абстракции. Принцип абстракции отвечает за выделение значимых свойств и методов в отдельный класс, опуская незначимые.</li><li>Инкапсуляция. Представим, что мы описываем класс, отвечающий за движение руки. В нем есть публичный метод - <code>двигать_рукой</code>, который доступен для вызова из других классов. С движением руки связаны другие методы, например <code>двигать_сустав</code> или <code>скорость_нейроимпульса</code>, которые нельзя менять, иначе рука не будет двигаться. Мы делаем их приватными, недоступными для публичного вызова и успешно избегаем изменений. Суть инкапсуляции - возможность сокрытия свойств и методов, предоставляя публичный интерфейс для взаимодействия с классом.</li><li>Наследование. Все мы производные от наших родителей. Мы унаследовали от них какие-то базовые свойства, но при этом регулярно расширяем их, формируя новый класс, например в процессе обучения. Суть наследования - возможность создавать дочерний класс от родительского, который может перенять его свойства и методы, расширить или переопределить их.</li><li>Полиморфизм. До того, как создать машину, мы определяем для нее общие свойства и возможности: ехать, тормозить, двигатель, колеса. Все эти свойства отличаются для различных типов машин. Полиморфизм позволяет определить один общий интерфейс для объектов с разной реализацией.</li></ol> Выделяют основные классификации паттернов проектирования:<ol><li>Порождающие(Creational) паттерны позволяют оптимизировать процесс создания объектов через создание абстрактных интерфейсов. Основные шаблоны: Абстрактная фабрика (Abstract Factory), Фабрика (Factory), Строитель (Builder), Одиночка (Singleton), Прототип (Prototype) и другие.</li><li>Структурные(Structural) паттерны формируют сложные структуры, расширяющие возможности одного или нескольких объектов. Основные шаблоны: Адаптер (Adapter), Мост (Bridge), Компоновщик (Composite), Декоратор (Decorator), Фасад (Facade), Заместитель (Proxy) и другие.</li><li>Поведенческие(Behavioral) паттерны позволяют улучшить качество взаимодействия между объектами. Основные шаблоны: Цепочка обязанностей (Chain of responsibility), Команда (Command), Интерпретатор (Interpreter), Итератор (Iterator), Посредник (Mediator), Хранитель (Memento), Наблюдатель (Observer) и другие.</li></ol> Шаблонов проектирования очень много, но среди них есть такие, которые встречаются чаще других. Вот их мы и начнем рассматривать в следующих статьях.

e111e5d73a1fdf53bcad97b239db0497_1.jpg

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

шаблоныпроектирования

Введение в паттерны проектирования в разработке программного обеспечения

ff21622e97c4a4ec22690e32436197a1_2.jpg

В этой статье мы рассмотрим то, как можно обезопасить доступ к облачным ресурсам предприятия с помощью VPN

сети

Зачем VPN бизнесу?

Всем привет! 👋🏼Сегодня мы поговорим о неверной оценке стоимости разработки ИТ решений. Эта боль - одна из основных для предприятий и стартапов, включая самих ИТ подрядчиков. Рассмотрим, как, в среднем, происходит процесс заказа аутсорс разработки:1. Появляется необходимость что-то оптимизировать в бизнесе, либо просто стать более инновационными, либо создать бизнес/новое направление вокруг ИТ решения.2. Происходит мозгоштурм в отдельных отделах или всей компанией.3. Рождается идея ИТ решения: мобильное приложение, сайт, интеграция, CRM, ERP, IoT решение.4. Назначается ответственный, чаще всего, с низкими компетенциям в ИТ, сотрудник. Начинается проработка идеи. Даже если в компании есть ИТ отдел, далеко не факт, что он компетентен в отношении ценообразования ИТ решений. И это абсолютно нормально.5. Идея становится концептом.6. Начинается поиск подрядчика.7. Анализ предложений. Вот тут и остановимся. Одна из основных проблем, ответственного за проект, сотрудника - незнание реальной стоимости разработки ИТ решения. Нужно понимать, что в формировании цены много факторов, а не только стоимость человеко-часа. Что же может пойти не так, когда вы не знаете реальную стоимость разработки ИТ решения:1. Вы&nbsp;можете получить все предложения с завышенной стоимостью, даже если выберете самое дешёвое.2. Вы можете получить предложение от компании, которая не смогла трезво оценить стоимость, демпинганула в погоне за проектом, а уже в процессе реализации поняла, что ей не хватит ресурсов. В-первом случае вы просто переплатите и, далеко не факт, что получите качественные услуги. Во-втором случае вы рискуете ни только потерять деньги, но ещё и не получить продукт. Более 10 лет я занимаюсь коммерческой разработкой ИТ решений и сформировал собственный подход к ценообразованию, который учитывает большинство нюансов как со стороны заказчика, так и со стороны подрядчика. Если вам нужна помощь в этом вопросе, то смело обращайтесь ко мне 🙌🏼

8f1efc5c94ccc694af29460c64c78d38_2.jpg

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

консалтинг

Неверная оценка стоимости услуг ИТ подрядчика

В прошлой <a href="https://galiullin.online/blog/GEg8qEVER5" rel="noopener noreferrer" target="_blank">статье</a> мы познакомились с моделью OSI. Пришло время рассмотреть подробнее каждый из уровней. <h2>Физический уровень</h2> Этот уровень модели OSI отвечает за передачу потока битов по физическим каналам связи - различные кабеля и беспроводные линии связи. Функции физического уровня реализуются на всех устройствах, подключенных к сети. У компьютера эту функцию выполняет сетевой адаптер, а со стороны промежуточных сетевых устройств - маршрутизаторы, коммутаторы и др. На этом уровне не происходит никакого анализа данных. Основная задача - доставить, без искажений, поток битов, в соответствии с выбранным кодированием и интервалом между соседними битами. <h2>Канальный уровень</h2> Это уровень предоставляет, вышележащему, сетевому, следующие услуги:<ul><li>установление логического соединения между взаимодействующими узлами;</li><li>согласование в рамках соединения скоростей получения и отправки информации;</li><li>обеспечение надежной передачи, обнаружение и коррекция ошибок.</li></ul> Протоколы канального уровня реализуются как на конечных узлах (сетевые адаптеры), так и на всех промежуточных сетевых устройствах (маршрутизаторы и др). Единица данных данного уровня - кадр. В поле данных кадра размещается сообщение сетевого уровня, а в заголовке - служебная информация, включающая адрес назначения. Канальный уровень может обеспечить надежность передачи, например, путем фиксирования границ кадра, помещая специальную последовательность битов в его начало и конец, а затем добавляя к кадру контрольную сумму. На стороне получателя канальный уровень группирует биты, поступающие с физического уровня, в кадры, снова вычисляет контрольную сумму полученных данных и сравнивает результат с контрольной суммой, переданной в кадре. Если они совпадают, то кадр считается правильным. Если же контрольные суммы не совпадают, то фиксируется ошибка. <h2>Сетевой уровень</h2> На мой взгляд этот уровень один из наиболее значимых уровней модели. Он является связующим звеном для разных сетей, которые используют свою технологию канального уровня, например сети Ethernet, FDDI, Token Ring. Без этого уровня невозможно передать сообщение из сети Ethernet в сеть FDDI. Функции сетевого уровня реализуются:<ul><li>группой протоколов;</li><li>маршрутизаторами.</li></ul> Маршрутизаторы могут быть как программные, поставляемые с операционной системой, так и аппаратные, отдельные устройства, которые чаще всего и отвечают за этот уровень. Единица данных сетевого уровня - пакет, который образуется в результате добавления к данных вышестоящего уровня соответствующих заголовков. Заголовок пакетов сетевого уровня наряду с другой информацией содержит данные об адресе назначения пакета. Чтобы пакеты были доставлены любому узлу в составной сети, они должны иметь уникальные адреса в ее пределах - сетевые или глобальные. Определение маршрута - это еще одна задача данного уровня, которая описывает маршрут, через который должен пройти пакет. Как правило маршрут состоит из последовательности других маршрутизаторов. Информацию о топологии связей маршрутизатор хранит в таблицах маршрутизации. <h2>Транспортный уровень</h2> Этот уровень отвечает за обеспечение надежной передачи данных для верхних уровней модели с той степенью надежности, которая им требуется. Модель OSI определяет пять классов транспортного сервиса от низшего 0 и до высшего 4. Классы отличаются: срочностью, возобновляемостью соединения, наличием средств мультиплексирования соединений, способностью к обнаружению искажений пакетов данных. Выбор транспортного протокола зависит от потребностей конкретного приложения, например для медиастримминговых сервисов не так важны возможные потери пакетов, что не скажешь, например про файловые серверы. Самые яркие представители протоколов данного уровня - протоколы TCP и UDP стека TCP/IP. <h2>Сеансовый уровень</h2> Этот уровень управляет взаимодействием сторон: фиксирует, какая из сторон является активной в настоящий момент и предоставляет инструменты для синхронизации сеанса. Функции данного уровня часто объединяются с функциями прикладного уровня и реализуются в одном протоколе.<h2> </h2><h2>Уровень представления</h2> Благодаря этому уровню информация, передаваемая прикладным уровнем одной системы, понятна прикладному уровню другой. Еще на этом уровне может выполняться шифрование и дешифрование данных, например с помощью протокола SSL, скажите/распаковка информации, кодирование медиафайлов.<h2> </h2><h2>Прикладной уровень</h2> Это тот уровень, с которым взаимодействуют приложения. На этом уровне происходит аутентификация, автризация, определение требований к защищенности сеанса и др. Для запросов к этому уровню используются системные вызовы операционной системы, образующие API. Примеры протоколов прикладного уровня: SSH, FTP, HTTP и др. <h2>Заключение</h2> Мы в общих чертах рассмотрели все уровни модели OSI, что является полезным знанием. В следующих статьях начнем углубляться в стек TCP/IP.

35b3cc438762e66fcae1a9a1f914634f_osi.jpg

В этой статье мы более подробно рассмотрим каждый из уровней модели OSI