Заметил дисбаланс. В сети полно правильных методологий, как решать задачи, и что с ними делать, но стоит запустить конкретный инструмент... Видим банальный TO-DO List c папками. А можно иначе?
Привет! Это Ахмад из botcreators.ru. Мы создаем чат-ботов и Telegram Apps, которых на конструкторе не соберешь. С интеграциями, на вашей корпоративной инфраструктуре, это когда сложнее, чем автоворонки.
Обсуждаем проекты и консультируем компании даже на этапе идеи. ТЗ напишем сами. Заявку можно оставить в нашем чат-боте.
По существу и кратко
Сейчас, любой таск-трекер:
набор атрибутов (сроки, исполнитель, проритет и т.д.);
название задачи;
описание задачи;
папки с проектами.
По-другому. Поведение таск-трекера может выглядеть так:
выдели три дела на день, а не список бесконечных задач;
разогревающие рутинные дела, чтобы войти в «состояние потока»;
напротив каждой задачи вопросы «это твоя задача или кому-то можно поручить?», «какие блокировки есть для выполнения задачи»?
напротив задачи минимальное действие в сторону ее выполнения;
что-то еще интересненькое, вовлекающее.
По существу, но развернуто
На самом деле, не сразу побежал сюда писать, что меня не устраивает положение вещей. Перепробовал за многолетнюю карьеру самые популярные инструменты: Jira/Trello/Asana/Битрикс. Но все не то. Бывает же так, все пользуются, а мне как-то не то.
Есть самый базовый тезис: трекеры задач просто фиксируют положение вещей, но никак не создают направленности выполнения задач. Думаю, согласитесь, большая часть сил уходит на размышления с самим собой, так называемый торг. А с чего начать, как подступиться к задаче. И тут каждый подставит свой коронный вопрос «а надо ли», «а получится ли»?
Причем следующий тезис тоже всем знаком. Как только втянешься в задачу, все идет по маслу. Другого человека посадили за задачу? Да нет, тот же самый, просто прояснилась пелена и теперь можно делать задачу. Так почему бы таск-трекеру не взять на себя эту задачу вовлечения? Ты ж трекер, трекай меня. Мне не нужно помадоро-трекер, мне нужно чтобы в начале дня сказали: вот твои задачи, выбери три, которые будешь делать, а остальное пока скроем от тебя.
Про рутинные дела
Прикольно же, утром открыл и первая автоматическая задача, проверить почту или прочитать телеграм чаты за прошлый день. Все дело сделано, можно переходить дальше. Получается некий визард, вовлекает в работу, а не сразу сто задач, пожалуйста.
Про чужие задачи и блокировки
Не знаю как у вас, а я периодически страдаю такой фигней. Мешаю команде работать. Задача пустяковая, но я уже выезжаю со своими «ценными» советами. Лечусь от того, но лечение проходило бы комфортно, будь напротив задачи вопрос
А это вообще твоя задача?
И все, уже сложнее будет забрать на себя лишних задач. Или еще такое бывает? Задача кажется громадной, непреступной, а там на входе нужно микро-действие сделать и все, потом как по нотам. Когда создаешь задачу можно указать это микро-действие и с него начнется выполнение задачи. Причем через пару дней на вспоминание этого микро-действия может уйти до получаса.
Чего не хватает этой статье
Очевидно, статья с заголовком про продуктивность должна включать методику. Их множество: Матрица Эйзенхауэра, ставьте цели по Smart. Да хоть бутсы Беккенбауэра. Думаю, не в этом суть. Методик пруд пруди, но задачи быстрее от этого не двигаются.
Наверно, это первая статья моя без картинок внутри. А нечего показывать, как показать то, чего нет в современном софте.
Кстати, даже заходил на глубинные интервью к самым популярным создателям таск-трекеров из РФ. Но пока, кроме косметических изменений за 3 года подвижек не вижу.
-------
А у вас как дела с постановкой задач? Где ведете свои задачи? Может уже есть софт, который все это умеет?
Кстати, у меня наконец-то появился Телеграм-канал. Пишу простым языком о технологиях и буднях нашей ИТ-компании. Все очень даже недушно там. Заходите.
Телега стала намного удобнее, когда в группах появились темы. До этого все сообщения были сплошной стеной, а сейчас удобно, можно разбивать на подтемы.
А когда над продуктом только начинается работа, куча разных тезисов и идей приходит в голову. Их нужно куда то сохранять. У меня вот такие темы на каждый стартующий продукт:
🔍 Смыслы - все про вижн продукта, зачем он появился
🚀 Продвижение - все маркетинговые идеи, текста для креативов, статей
🌐 Лендинг - как будет выглядеть лендинг продукта
🔄 Альтернативные применения - а как по-другому продукт еще можно применить
📦 Продакт - про метрики, гипотезы
💸 Pay-wall - про монетизацию
👥 10 клиентов - кому написать первым и рассказать про продукт
✨ Фичи - бэк лог на будушие спринты
🔧 Авто-воронка - если у тебя для продвижения есть только бот, что будет в воронке?
📚 Референсы - похожие продукты / идеи из других проектов
💬 Обратная связь - что сказали люди о продукты, первая ОС
🛠 Технические вопросы - все технические нюансы
Конечно, для больших и понятных проектов есть другие подходы, но когда идея только зародилась и ее нужно развить до первых пользователей, есть вот такой способ, работает на ура.
P.S. Чтобы сделать темы в настройках группы включаем тумблер "темы"
Если вам кажется, что заказчик пришел с расплывчатым ТЗ или нужно задать очередной вопрос для уточнения требований. Вам не кажется. Настало время по-настоящему сложного ТЗ.
Привет! Это Ахмад из botcreators.ru. Мы создаем чат-ботов и Telegram Apps, которых на конструкторе не соберешь. С интеграциями, на вашей корпоративной инфраструктуре, это когда сложнее, чем автоворонки.
Обсуждаем проекты и консультируем компании даже на этапе идеи. ТЗ напишем сами. Заявку можно оставить в нашем чат-боте.
Как всё начиналось
За свою карьеру я написал более сотни технических заданий на разработку ПО, еще больше ТЗ мы с командой составили при реализации наших проектов. К нам приходят как с готовыми ТЗ на 50 страниц, так и с одной строчкой "нужен чат-бот для выставки". Дальше всё понятно: проектирование, разработка, тестирование, запуск. Даже свою методологию создали для молниеносного запуска небольших ИТ-проектов.
Если видишь сотню ТЗ за месяц, невольно думаешь, а где предел сложности, что такого нужно написать в ТЗ, чтобы мы прям удивились. Пришла идея смоделировать такое ТЗ, об этом и статья.
Когда наскучили обычные задачи
Из чего обычно состоит любой современный веб-софт? Интерфейсы, клиентская бизнес-логика, объекты в базе данных, авторизация, аналитика. Все знакомые слова. Что может пойти не так.
Вам чат-ботА или чат-бОта?
Есть такой креативный прием — усложнить задачу до нереальных требований и прикинуть, что получается. Инсайты гарантированы. Например, вы делаете софт для автоматической заливки видео с галереи смартфона на YouTube, а его вдруг блокируют.
За абсурдом я прямо проследовал к ChatGPT, и начался мозговой штурм. ТЗ в первом приближении выглядело так:
Я делаю чат-ботов. Напиши сложное ТЗ, которое реально заставит меня задуматься
В первой итерации ничего интересного. Под сложностью LLМ-ка понимала интеграцию с CRM и ERP-системами и обработку естественного языка. Мы такое видим каждый день.
Хоть чат-бот, на первый взгляд, простая штука, интеграции и серверную логику никто не отменял. Этим, кстати, мне и нравятся чат-боты. Простой интерфейс, запрос-ответ. А за ним все сложное спрятано от пользователя.
Настало время правок
Как усложнить задачу? Особо не выдумывая, вбрасываю такой тезис:
Ха! Я такое напишу за один вечер, с закрытыми глазами, усложняй ТЗ еще
Затем модель предложила добавить в чат-бота мультиязычность, адаптивность в обучении и сквозное шифрование на всех уровнях.
Но я же не за этим пришел, мне нужна действительно сложная задача:
Во-первых, это снова элементарное ТЗ, я такое смогу сделать за пару часов, во-вторых, пиши как-то более кратко и емко. Поставь нормально задачу, чтобы я хоть на 5 секунд задумался, усложняй задачу еще
И вот здесь начинается интересное. А именно — динамично предсказывать пожелания пользователя на основе многослойных нейронных сетей. Такого от заказчиков действительно не поступало.
Допустим, задача выглядит сложной только на первый взгляд:
У тебя 2 недели уйдет на это, а у меня пару секунд, еще пару секунд на деплой. Напиши по-настоящему сложное ТЗ
Следующий виток "сознания" коснулся автономной работы чат-ботов в условиях распределенной сети без централизованного управления. Что-то вроде чат-ботов в блокчейне? Ок, идем дальше.
Ты мне даешь месяц, а я уже тебе скинул исходный код чат-бота за 2 секунды, это не задача, а прогулка, понимаешь? Напиши сложнейшее ТЗ, которое только ты можешь представить, и плиз попроще пиши, не надо сложных слов
И тут мы наконец-то поняли друг друга. LLM-ка предложила:
Создать чат-бота, который научится программировать с нуля, без использования готовых примеров и подсказок, и самостоятельно создаст работающую копию самого себя, улучшенную по сравнению с оригиналом.
Просто и понятно
Действительно, просто пусть сам чат-бот научится программировать и улучшать себя. Идеально. Разве это все? Это вершина?
Да, и снова ты написал какую-то детскую задачу. Можно ли посложнее что-то сюда написать? А не вот эти простые задачи
На этом этапе мы прошли экстремум функции. Дальше уже будет спад "креативности". А вершина выглядит так: Разработать многоагентную систему чат-ботов, которые самостоятельно эволюционируют и координируют свои действия для решения неизвестных и непредсказуемых задач в полностью автономной среде.
В общем, они сами разберутся, главное не мешать. Непонятные задачи? Скоординируются и решат. Все будет ок.
Еще вот это понравилось:
Разработать ИИ-систему, которая самостоятельно создаст новую, фундаментально неизвестную науке область знаний, полностью осознает и докажет её значимость, а затем разработает практические приложения, которые перевернут современное понимание реальности.
Науку новую создать сколько будет стоить? А по времени сколько займет, примерно +/-?
Вместо итогов
Полный вариант нашего "мозгового штурма" можно глянуть здесь.
Нейронки подходят не только для генерации картинок. Бредогенерация позволяет взглянуть на привычные вещи под другим углом.
А какие ТЗ или хотелки от пользователей удивили именно вас?
Кстати, у меня наконец-то появился Телеграм-канал. Пишу простым языком о технологиях и буднях нашей ИТ-компании. Все очень даже недушно там. Заходите. Желаю всем понятных ТЗ, ну или как получится.
Кто-то предлагает освоить популярную веб-профессию за 6 месяцев. Кто-то даже предлагает оплатить курсы после трудоустройства. Может все вокруг врут, все намного проще и достаточно посмотреть десяток голливудских фильмов? Давайте разбираться.
Это Ахмад из Botcreators. Собрал примеры работ горе-программистов из известных фильмов. Проводим код-ревью. Постарался без спойлеров.
1. Инопланетный код (2017)
Главный герой не просто программист, а ведущий шифровальщик страны. Это вам не формочки клепать на прогрессивном JS-фреймворке. Все бы ничего, но Алекс настолько прозрел в своем ремесле, что с помощью стандартной библиотеки Java сумел расшифровать послание из будущего.
За выбор библиотек можно поставить лайк. Ведь действительно было близко, крипто-библиотека Java, инопланетный шифр, рядом, рядом.
2. Опасная правда (2001)
В этот раз гений-программист попадает под влияние харизматичного CEO крупной корпорации. Который на поверку оказывается злодеем. Вместо того, чтобы аккуратно форкать проекты опенсорсеров, он убивает владельцев кода. А код присваивает себе.
Но вскоре и до главного героя начинает доходить, что гениальный код писать не про этого СЕО. Антагонист лучше всего умеет бравировать чужим кодом и хрустеть чипсами.
Фильм на самом деле пестрит отсылками к культовым ИТ-личностям и событиям. Сам СЕО как две капли воды похож на Билла Гейтса. А его стартап что уж очень напоминает будущее детище Илона Маска - Starlink. Действительно, живем в эпоху постмодерна.
Но у нас здесь не философский кружок, вернемся к нашему чудо-разработчику.
На камеру своего гения протагонист показывает в середине фильма. Пробравшись ночью в недра корпоративного ЦОДа, и одурив горе-охраников, Майло добирается до терминала, замаскированного под детскую комнату. Ловко набивая на клавиатуре хот-кеи, открывает консоль.
И оказывается, чтобы получить доступ к видео-потоку IP-камер достаточно выбрать нужный UNIX-процесс. А пользователь ОС это точный указатель на владельца камеры.
Пару ловких команд и импровизированная детская превращается в центр управления полетов всех горе-контрибьютеров.
Отдельного внимания заслуживает шайка охраников-девопсов.
Соорудили, попивая кофе по ночам, вот такой CI/CD pipe-line:
камеры зумят экран опенсорсера;
некая OCR-тулза (не показали жаль, какая) переводит код с фото, в файлы
и остается дело техники - все правильно смержить, с этим справится каждый охранник
Код сохранен, осталось записать его на компакт диск и передать на презентацию СЕО. Он то точно знает как показать продукт с лучшей стороны.
Если статья наберет 30 лайков, выпущу продолжение, в нем, например, изучим SQL через фильм "Девушка с татуировкой дракона". В подборку, конечно, не будут включены всякие треш-сцены, где программист просто тапает по клавиатуре, а на экране бежит код.
Кстати, если вы только начинаете свой путь в управлении продуктом у меня есть гайд по проведению "Глубинных интервью". Как искать первых желающих, как подготовиться и какие вопросы задавать. Мне бы кто такое рассказал пару лет назад...Вот здесь лежит презентация.
Я уже давно с удовольствием читаю о процессах в других компаниях, теперь решился рассказать о «внутренней кухне» в BotCreators.
Наша главная гордость, ну, помимо самой команды (люди — это правда важно), это наша методология. Её ещё называют фреймворком или по-простому, по-нашему — образец. Это основа, на которой держится наша работа.
Раньше на предпроектную подготовку у нас уходило от одной до двух недель. Сейчас мы с командой успеваем полностью вкатиться в процессы и начать писать код уже на второй-третий день.
Но это сейчас так))
Всему виной (один?) непростительный косяк
Хотелось бы сказать, что один… За четыре года мы «успели» многое: и просчитаться с бюджетом, и сместить сроки, и забыть о метриках, и упустить контроль за конкретным аспектом в работе.
Глобально же нашей проблемой была совсем неочевидная причина.
Мы работали по ТЗ.
Вот прям брали его и делали всё, как там написано. И ничего больше. Системы не было.
В 2022 году, когда мы почувствовали, что ошибки стали повторяться, пришла пора принимать меры. Так появилась наша методология.
И всё сразу стало хорошо (нет)
Надо было с чего-то начинать, поэтому мы открыли Miro и стали набрасывать идеи. Сидели и прям на созвонах обсуждали, что нам надо.
Посидели, подумали, зафиксировали и пошли работать дальше. Никто ни от кого не требовал готовые решения здесь и сейчас. А что успели записать, сразу обкатывали на новых проектах.
Забегая вперёд, скажу, что и в текущем виде — это ещё не конечный вариант. Наверное, именно это отличает наш подход от многих других: мы постепенно привыкаем к чему-то новому, а всё ненужное отбрасываем только после того, как попробовали лично.
Показываю, что внутри
Каждый из элементов можно разделить на четыре группы. К слову, я с ними вам Америку не открою, это база, которую обычно использует большинство IT-компаний, даже если речь заходит не про описание методологии, а просто о процессах в команде.
А уже внутри групп как раз те элементы, которые мы в BotCreators используем в работе.
В формате видео доску показывали на YouTube
А теперь подробнее о каждом из элементов.
1) Бизнес-процессы
Установка перед стартом проекта и Планирование. Эти элементы у нас под NDA, но концептуально понять их содержание можно уже из названия. В «Установке» мы подробно расписываем, какие шаги нужно пройти, чтобы о сотрудничестве не жалели ни мы, ни заказчик.
В «Планировании» указываем наши мастхэвы: что используем, чтобы не сдвигались сроки и задачи можно было бы выполнять качественно.
Табличная структура и стикеры помогают учесть вообще всё, что только можно
Стейкхолдеры проекта. Те, с кем вы будете согласовывать проект. Обычно это отдельные люди, которые несут ответственность за реализацию проекта, но в маленьких компаниях стейкхолдером может быть и сам заказчик — тот, кто предложил такой проект сделать (или отвечает за финансирование).
Ограничения проекта. К ним мы относим конкретные сроки, нюансы с бюджетом и сложные интеграции. Например, на нашей доске можно увидеть ограничение по времени — «Запуск до НГ, строго». Это значит, что если сдать проект позже, то для заказчика он уже будет неактуален.
Риски. Сюда мы относим какие-то специфичные сложности.
Метрики. Всё, что можно посчитать, лучше посчитать. Но в первую очередь, конечно, нужно следить за источниками трафика, за количеством запусков (или регистраций) и за активностью пользователей (спросили, ответили, проголосовали и т.п.).
Риски мы заполняем нечасто, но такой элемент всё равно должен быть в каждом образце
Инфоблок. Сюда мы пишем все ссылки по проекту, которые должны быть под рукой. Обычно это задача в Битриксе, ТЗ, документация, прототипы и ссылка на внешний ресурс, такой, как GitLab.
Командные роли. В нашей команде 30+ человек, поэтому мы отдельно прописываем, кого на какой проект назначили.
ТЗ. В этом элементе мы пишем вопросы, которые хотели бы задать заказчику прежде, чем подготовим детальное техническое задание.
Отдельно пишем вопросы по проекту в целом
Приёмка: функциональность, проверка на безопасность и нагрузка. Здесь указываем важные моменты, которые нужно учитывать во время разработки и тестирования.
Рефлексия. Она важна, когда в компании часто меняются проекты. Если просто переходить с проекта на проект, ощущения завершения не будет. Также не будут сделаны выводы, а значит, есть риск, что ошибки будут повторяться и в будущем.
Для «Рефлексии» заготовленных стикеров нет. Это пространство, где мысли не ограничены какими-то рамками
Дорожная карта. Обязательно прописываем этапы и дедлайны. Потому что если нет понимания, что мы делаем и когда будем это согласовывать, значит, конца проекту не будет. Конкретные задачи и сроки дают ясное понимание команде и спокойствие заказчику.
Почти все элементы «Дорожной карты» меняются от проекта к проекту
Описание бизнес-процессов. Такой элемент помогает приблизить команду и заказчика к единому видению.
Уже при построении этой схемы можно наткнуться на узкие места в разработке и увидеть возможности для улучшения
Форсайт. Даёт глобальное понимание «что, зачем, для кого». Не является обязательным элементом, но как один из методов, помогающих запустить мышление, неплохой вариант.
Чтобы быстро прийти к цели проекта, начните с «Форсайта»
2) Проектирование
Функциональность проекта. Здесь мы схематично соединяем техническую и «пользовательскую» составляющие, чтобы наглядно декомпозировать проект.
Розовым помечаем то, что относится к разработке. Фиолетовым — то, что относится к элементам, которые будет видеть пользователь
User Story Map. Тоже под NDA, но о пользе рассказать могу. Такой элемент помогает поставить приоритеты главным задачам проекта, учитывая при этом потребности пользователей.
CJM. Классическая схема, которая показывает путь пользователя. Нашей команде такая схема позволяет посмотреть на проект его глазами.
Помимо стикеров мы также используем эмодзи — предполагаемые эмоции пользователя
Экраны чат-бота. Мы сделали уже больше сотни чат-ботов, поэтому теперь свою экспертизу можем визуализировать на доске в Miro, чтобы для будущих разработок тратить минимальное время на анализ и структуру. Фактически это заготовка для любого чат-бота. Именно с неё мы начинаем создавать структуру для конкретного проекта.
Стрелками помечаем «движение» пользователя в чат-боте, а стикерами — важные моменты, которые нужно учитывать в проекте
Оформление чат-бота. Сюда детально пишем, какой нужен контент и как будет выглядеть чат-бот для пользователя.
Возле каждого элемента из второй ветки указываем ответственного за него
Уведомления чат-бота. Здесь такая же логика, как и у «Экранов чат-бота», но с акцентом на одну его функцию — отправку уведомлений.
Здесь также показываем взаимосвязь экранов, а важную информацию указываем на стикерах
Админка. Это один из тех элементов, которые мы добавили совсем недавно. Пока сюда загрузили только скриншоты — референсы для вдохновения.
3) Разработка
Схема базы данных. Этот элемент нужен в первую очередь разработчику, чтобы он мог показать аналитику и PM, как его в понимании она должна выглядеть.
Сейчас база данных нужна для каждого проекта, поэтому этот элемент мы используем постоянно
Описание архитектуры. Здесь соединяем наши технические составляющие с техническими составляющими заказчика.
Указываем всё, что есть: структуры серверов, сервисы и микросервисы
Описание API. Заполняем этот элемент, когда в проект планируем интегрировать внешний сервис. Если не описывать протоколы обмена, нужно быть готовым взять на себя большой риск. Незачем зря рисковать, поэтому этот раздел мы тоже не пропускаем.
Чаще всего эту таблицу заполняет PM или аналитик
4) Тестирование
Визуальное представление продукта. Не путать с референсами. Здесь QA-инженер должен видеть уже готовые макеты проекта. Можно просто указать ссылку на Фигму, если дизайн делали там, главное, чтобы эта ссылка была.
Экраны чат-бота.
Оформление чат-бота.
Уведомления чат-бота.
Приёмка: функциональность, проверка на безопасность и нагрузка.
Об этих элементах я уже рассказал выше, но не могу не упомянуть их и в контексте тестирования. Тестировщик должен понимать, с чем имеет дело.
→ Все знают, что делают общее дело: в любой момент каждый из команды может рассказать, чем занимается, и может наглядно увидеть, что получится в конце
→ Мы можем показывать клиенту промежуточные результаты. Он тоже понимает, какой проект в итоге получится
Главное преимущество
Теперь мы можем показывать MVP клиентам уже через три недели после подписания договора!
Что происходит после запуска проекта
То, что я показал здесь, относится только к старту проекта и к погружению в него. Для мониторинга, техподдержки и техобслуживания у нас есть отдельные доски. В них мы следим за тем, чтобы всё работало как надо и дальше.
То есть, стартанули, разработали, протестировали и дальше просто следим.
Но бывают ситуации, когда доску для старта одного и того же проекта мы используем несколько раз. Так происходит, когда для проекта нужны несколько итераций. Например, сначала делаем MVP, потом интегрируем внешние приложения к уже существующему проекту, затем добавляем в готовый проект с интегрированными сервисами дополнительные функции.
Что планируем делать дальше
Мы с командой продолжаем развивать уже существующую методологию: добавляем туда новые элементы и дорабатываем существующие. В ближайшее время хотим поразмышлять над UX для чат-ботов и над улучшением прототипирования существующих экранов.
Также планируем заняться визуализацией собственной админки. У нас уже есть рабочий вариант, но много всего полезного туда ещё можно добавить.
Для тех, кто спешит
Проанализируйте уже завершённые проекты. Что их всех связывает?
Как работает ваша команда? Они всё успевают?
Выделите повторяющиеся моменты и подберите подходящее решение. Например, сделайте свою методологию.
Начните с добавления тех элементов, которые сразу принесут пользу.
Постепенно улучшайте уже существующую систему. Проблемы начнутся тогда, когда вы решите, что система уже достигла совершенства.
Если вы искали команду с вдумчивым подходом — приходите в BotCreators, подумаем вместе. Как начнём работать с вами, вы теперь знаете 😏
По образованию я авиационный инженер. С детства увлекался техникой: мне всегда было интересно устройство гаджетов, автомобилей, самолётов. Поэтому закономерным выбором стал Московский Авиационный Институт, в котором ребят учат строить, создавать и поднимать в воздух многотонные машины.
Закончив институт, к сожалению или к счастью, я не долго проработал в профессии. Для себя я понял, что есть более интересное занятие — написание программ, составление новых программных продуктов.
Я прошёл путь от рядового разработчика до управленца целой команды разработки. И уже тогда понял, что на одном техническом скилле сделать по-настоящему сложный проект невозможно.
Программист в одиночку может осилить небольшой проект, но когда идет речь о федеральном проекте, на первый план выходит команда. О таких компетенциях и секретах создания качественных ИТ-продуктов я сегодня и расскажу.
Ловушки, в которые попадают начинающие предприниматели
Подавляющее число компаний и веб-студий, занимающихся разработкой софта на заказ, начинаются с одного-двух энтузиастов, которые в прошлом были программистами, но в какой-то момент поняли, что выросли и хотят делать нечто большее, чем просто выполнять задачи по проекту.
Здесь кроется первая ловушка, в которую попадают начинающие основатели: они продолжают мыслить как разработчики, хотя уже сменили роль на управленца и предпринимателя. От того, насколько быстро осознаётся этот факт, зависит успех предприятия на начальном этапе.
Тут на первый план выступают навыки делегирования, переговоров, управления командой. Сервисная компания — это прежде всего про людей, про команду. Поэтому сервисную компанию не может тащить на себе один человек.
Следующий важный момент — приход к пониманию, что основное взаимодействие лежит за периметром компании. Важны навыки общения и коммуникации, желание разговаривать с клиентом, слышать его боли и запросы. Подходить к коммуникации максимально тщательно, так как именно клиенты приходят в компанию, именно они формируют спрос, именно за их словами кроются потребности и ответы на то, что нужно делать.
Основатель сервисной компании должен быть на короткой ноге с клиентом и быть почти другом, чтобы в следующий раз, когда у клиента возникнет новая потребность, вспомнили снова именно про него.
Но на одном скилле коммуникации сложно сделать продукт. Клиент приходит за созданием некого осязаемого, хоть и виртуального диджитал-проекта. Поэтому важным тезисом является построение прочного менеджмента и регулярного ведения проекта понятным образом для клиента.
На что обратить внимание при общении с клиентом
Первое — постоянная отчётность по проекту. Для клиента процесс вашей работы не должен быть скрытой тайной за семью печатями. Наоборот, я настаиваю на том, чтобы сервисные компании держали клиентов в курсе происходящего максимально подробно.
В этом есть много плюсов. Осведомленность снимает нервозность, страхи, тревоги клиента о проекте и конечной цели, к которой вы вместе идёте.
Под осведомлённостью я подразумеваю чёткое поэтапное планирование проектов. Если проект сложный и затяжной, клиент может и не знать о всех трудностях. Важно донести до него, что из точки А в точку В мы с ним пройдём через серию других точек, но в конечном счёте цель будет достигнута.
Если говорить только про конечную точку В и не рассказывать про промежуточные результаты, это создаст напряжённость, и проект станет сложно управляемым. Также важно понимать, что клиент не будет расставлять приоритеты вместо самой компании. Когда клиент приходит получить услугу, он ожидает, что попадёт к профессионалам, которые возьмут на себя решение всех сложностей.
Следующий важный момент немного спорный: нужно ли давать клиенту возможность управлять процессом разработки? Я придерживаюсь мнения, что клиенту нужно показывать промежуточные результаты, но это должно быть как бы «за стеклом».
Это значит, что вы собираете продукт, клиент видит, но не управляет. Впускать клиента в процесс чревато. Клиент по незнанию может давать такие корректировки, которые будут нарушать технологический процесс.
Тут нужно уловить тонкий баланс между демонстрацией, открытостью и приверженностью своим принципам, которыми вы руководствуетесь.
У вас должна быть методология: фреймворки, принципы и технологии создания IT-продуктов.
Мы пришли к этому не сразу. Прошло 3 года и 2 кризиса, прежде чем мы достигли понимания, что должна быть методология. Это может быть эджайл или другие подходы. Вокруг этой методологии формируется как команда, так и ваш общий подход к делу. Отсутствие методологии приводит к хаосу в проекте.
Ещё момент, которому нужно научиться, — управлять ожиданиями клиента. Это значит слышать клиента, фиксировать моменты, которые он подсвечивает. Как это делаем мы: всё, что обсуждается на проекте, не проходит мимо нас. Каждая фраза, всё, что прозвучало на обсуждении, заносится в бэклог. В таких сервисных историях разработка идёт итеративно.
На первом этапе сделан один объём работ. На втором этапе при наличии бэклога у вас уже есть список задач, которые нужно развивать с клиентом, чтобы внедрить в продукт.
Наличие бэклог-фиксации обязательно — пишите записки на полях в журнале проекта. Должны быть какие-то «бортовые записи». Журнал проекта не должен быть пустым.
Следующий пункт — это контроль и оценка качества. Что не оценено, того нет. Поэтому всё, что можно занести в процесс по чек-листам, должно быть заведено в процесс контроля качества.
Мы должны давать подготовленный продукт, проверенный и протестированный. Клиент не проверяет качество, а получает продукт уже в рабочем состоянии.
Поэтому в компании должен быть хотя бы один специалист, который отвечает за тестирование и качество.
Как правильно закончить сотрудничество после сдачи проекта
Не спешите прощаться с клиентом, как только закончили продукт. Попросите обратную связь — это поможет в работе в дальнейшем. Мы к этому также пришли не сразу. Но теперь не представляем своё взаимодействие без этого пункта.
Начать советую с простого NPS-опроса. Это опрос, позволяющий в простом формате получить обратную связь через 10—15 вопросов: как сделан проект, что понравилось, что не понравилось.
Такой опросник станет для вас целым океаном инсайтов. Клиенты помогут понять, в какую сторону двигаться дальше, чтобы развиваться лучше и быстрее.
Конечно, ситуации бывают разные. Не всё может быть оценено объективно, но в большинстве случаев сбор такой обратной связи и её анализ помогают улучшить качество работы и сделать по-настоящему востребованный и хороший продукт.
Если недостаточно простого опроса, попробуйте методологию кастдевов — глубинных интервью с клиентом. Это уже полноценная рефлексия после завершения проекта, которая помогает полностью переосмыслить всё, что было сделано, и понять, как можно к чему-то подойти уже по-другому в следующий раз.
Почему я нанимаю самостоятельных людей без привязки к географии и выгоняю их во время с работы чтоб шли отдыхать. Про свои подходы к формированию команды и почему это помогает моему бизнесу расти.
Меня зовут Боков Ахмад, я основатель компании «Искусство Автоматизации». Уже 5 лет наша компания помогает бизнесу выстраивать цифровые коммуникации в социальных сетях и мессенджерах, а также автоматизировать рабочие процессы.
Счастье бизнеса. Когда мы говорим о таком абстрактном понятии, появляется противоречие. Ведь бизнес про цифры, показатели и результаты, где тут место счастью?
Мне такая дилемма много лет не давала покоя. Неужели до счастья сотрудников нет дела, ведь мы вместе делаем что-то общее?
Сейчас, когда я смог разрешить эту дилемму, я готов поделиться:
Как делать результат, но при этом не загоняться и не выгорать;
Как держать баланс между интересами компании и сотрудниками.
Отвечу по каждому из пунктов и поделюсь общими выводами.
Экологичные отношения в коллективе
— Создание благоприятной рабочей среды;
— участие в принятии решений и уважение;
— развитие карьеры и возможности роста.
Вот те принципы, на которых должно держаться видение компании, если она стремится к экологичной атмосфере.
В понятие благоприятной рабочей среды я вкладываю довольно понятные концепции.
Я уверен, что на работу мои коллеги приходят не выгорать, а раскрывать свой потенциал и получать удовлетворение от его раскрытия. Причём это чётко проговаривается уже на собеседовании: «У нас не выгорают».
Считаю, что нет ничего благородного в том, чтобы класть свои нервы и силы на алтарь работодателя. Если есть переработки, то это неправильно построенные процессы, и «затыкать» дыры в системе за счёт ментального здоровья сотрудников — это верх неэкологичности.
Моя задача как руководителя — настроить рабочий процесс так, чтобы в 18:00 все рабочие чаты замолкали, и сотрудники отправлялись заниматься своими личными делами.
А ещё не важно, где находится сотрудник — если от него приходят результаты, с которыми можно двигаться дальше — это в приоритете.
Сотруднику самому должно быть интересно то, чем он занимается. А если ему некомфортно, то никакие ухищрения в виде «слежки» не помогут его замотивировать лучше.
Но даже если с благоприятной средой и комфортной работой всё уладить, можно допустить другую ошибку: когда результат работы отдельного сотрудника не соотносят со вкладом в общее дело.
А ведь это необходимо для построения экологичного бизнеса, в котором сотрудники явно видят и понимают, как их действия или бездействия влияют на общее дело команды.
Ответственность каждого отдельного сотрудника за результат берётся из понимания, что я, как руководитель, не только делегирую задачи команде, но и наделяю команду необходимыми ресурсами и возможностью принимать самостоятельные решения.
Если поставить задачу сотруднику, а решение принять самостоятельно — будьте готовы к тому, что результата по этой конкретной задаче не будет. Соберёте несколько таких задач — и компания начнёт стагнировать. Вроде все работают, а эффективность околонулевая.
На что я смотрю при найме
Бизнес должен зарабатывать деньги — для этого он и создаётся. Но если в компании работают люди, а не роботы, о психологическом комфорте забывать ни в коем случае нельзя.
Какой ценой обычно добиваются показатели и результаты? Ценой уставших и измученных людей? Такой подход не для меня.
А вот чего я точно придерживаюсь, и что реально помогает нанимать крепкую команду, готов рассказать с удовольствием.
По моему пятилетнему опыту на сегодняшний момент есть три принципа, которыми я руководствуюсь при найме сотрудников, чтобы понять, что их «культурный код» совпадает с «кодом» нашей компании.
Первый принцип — нанимать самостоятельных людей, даже если у них ещё нет опыта. Главное — их готовность учиться и понимать важность организованности.
Второй принцип — построение экологичных отношений, даже если это уже давно стало мейнстримом. Новые ребята приходят к нам не чтобы отсидеть 8—9 часов, а чтобы сделать что-то полезное, принести пользу другим. Ничто так хорошо не зажигает коллег, как возможность приносить пользу. Это запрограммировано в нас на самом глубинном уровне.
Третий принцип — обещанное нужно сделать. Это простое понимание о честности своих намерений и действий, о том, что на нас можно положиться. Касается вообще всех: и команды, и клиентов. Если кто-то что-то пообещал — это при необходимости подробно обсуждается и обязательно выполняется.
Отдельный принцип, которого новые люди придерживаются сразу после найма — каждый сотрудник имеет право на ошибку. Это постоянно проговаривается и транслируется.
Благодаря такому подходу в команде снимается напряжение, а каждый отдельный сотрудник может открыться с новой стороны.
«Ты можешь ошибиться, за это тебе ничего не будет. Мы проанализируем ситуацию и сделаем выводы, а их закрепим в нашей базе знаний».
За какими компаниями будущее
Я считаю, что за бизнесами, в которых особое место уделяется сотрудникам и их развитию.
Это не про избитые лозунги, что кадры — наш основной актив. Это про реальные дела, про то, какое развитие может получить новый член команды. И это экологично: специалист делает свой вклад в общее дело и хочет получить что-то обратно.
Не получая ничего взамен, мы получаем разочарование и выгоревшего сотрудника.
Можно начать делать бизнес вообще без миссии и сформировать её уже по ходу работы, но чем больше сотрудников в вашей команде, тем важнее её придумать уже сейчас. На миссии и общем смысле строится и найм, и работа, и достижения.
Поймёте своё предназначение, определите благородные цели — и тогда строить процессы будет проще, ведь у вас появится конкретный ориентир.
Поделился своей рефлексией о ведении бизнеса. Надеюсь, было полезно. Найти мои другие размышления можно в книгах об IT. Писали об этом недавно пост в BotCreators, заглядывайте.
