Сокровищница знаний

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

Чем аутстафф персонала похож на дикий запад? Вспомните, как вообще появилось слово «хедхантер»: это перевод английского headhunter, буквально — охотник за головами. И нынешний аутстафф часто оборачивается хаотичной охотой на кандидатов вместо умного подбора персонала. Причина этого — появление компаний агентств, которые находят заказы на аутстафф персонала, запрашивают у партнеров наличие специалистов и отправляют их клиенту за комиссию. Казалось бы, вполне рабочая модель — но если посмотреть внимательнее, можно увидеть серьезные недостатки. Во-первых, у таких компаний обычно нет экспертизы в ИТ, поэтому им сложно найти максимально подходящего специалиста. Как и кадровые агентства, они могут ориентироваться только на соответствие резюме требованиям заказчика, но не способны провести техническое собеседование и оценить навыки. А значит, выше риск, что кандидат будет забракован клиентом. Во-вторых, пул специалистов у таких хедхантеров набирается по принципу сарафанного радио, когда люди обмениваются между собой контактами разработчиков. Как результат — несколько компаний могут прислать заказчику одного и того же специалиста. Клиент получает резюме кандидата и понимает, что он его уже собеседовал. Вряд ли у этой бизнес-модели большое будущее: после одного неудачного сотрудничества заказчик будет искать другие варианты.

Сегодня — завершающая часть цикла «Бизнес в поисках софта», где мы расскажем об облачных решениях. Предыдущие статьи можно прочитать по ссылкам: Ч.1 Бизнес в поисках софта: low-code и no-code Ч.2 PWA — браузер под капотом приложения

Мы продолжаем нашу подборку «Бизнес в поисках софта», и сегодня поговорим о PWA — Progressive Web Apps. Первую статью из цикла можно почитать тут: Бизнес в поисках софта: low-code и no-code

code

ТЗ — одна из самых сложных вещей в отношениях заказчика и технической команды. Это извечная проблема: клиенты редко умеют его писать, и исполнители не могут работать без него. Почему так происходит? Давайте сначала разберемся, что такое ТЗ. По сути, это технический документ, который описывает все требования к продукту. Проблема в том, что разработчик и заказчик чаще всего говорят на разных языках, поэтому для одного из них ТЗ другого выглядит как текст на китайском. Клиент мыслит категориями бизнеса, ему нужен продающий сайт. Для исполнителей понятие «продающий сайт» бесполезно: им требуется четкая инструкция, какие элементы должен включать в себя продукт, чтобы быть продающим. Так, при ремонте квартиры вы подробно рассказываете рабочим, какая кладка плитки должна быть в ванной, сколько розеток в гостиной, какой высоты натяжные потолки и какого бренда оконные пакеты. Если же вы придете с запросом сделать вам стильный ремонт — скорее всего, в финале выяснится, что представление о стиле у вас и у строительной бригады не совпадают. С техническим заданием для сайта или приложения все намного сложнее: например, может оказаться, что функционал сервиса технически нереализуем в том виде, в котором хочет его видеть клиент — поэтому продукт надо строить по-другому. Или что задача, которая кажется заказчику маленькой и несложной, на самом деле большая и трудоемкая. А значит, что работа займет больше времени, чем предполагалось, и сроки проекта будут сорваны.

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

Текст про интеграции хочется сразу проиллюстрировать наглядным примером. Однажды мы решили сделать нашему проджект-менеджеру сюрприз в честь дня рождения и подарить от всей команды кресло-пуф. Мы нашли подходящий товар в онлайн-магазине, заказали, оплатили. Ждем. Проходит день, два — в личном кабинете все еще висит статус «заказ в обработке». Звоним в компанию и слышим: «Простите, у нас очень большая загрузка, сейчас все сделаем». Не успели мы выдохнуть, как через пару часов поступает звонок от того же менеджера: извините, товара нет на складе. В итоге все кончилось хорошо: мы выбрали на сайте другую модель, компания бесплатно организовала срочную доставку, и Павел теперь пишет клиентам письма из глубины нового пуфа. Но эта ситуация хорошо иллюстрирует, как отсутствие интеграции сайта с внешними сервисами (в нашем случае с CRM и системой складского учета) мешает работе компании.  С примерами интеграций мы сталкиваемся каждый день: когда пишем в WhatsApp через виджет, оплачиваем покупку на сайте, авторизовываемся через соцсети, смотрим ролик без перехода на YouTube. Для аудитории такие интеграции — это, прежде всего, удобство и качество сервиса, для бизнеса — способ удерживать клиентов и оптимизировать процессы. Кроме того, внешние сервисы значительно облегчают вам работу: согласитесь, намного проще разместить на странице виджет Google Maps, чем самостоятельно отрисовывать карту города.