Жизненный цикл разработки ПО, фазы, процессы, модели.

Что такое Жизненный цикл разработки ПО (System/Software Development Life Cycle, SDLC)

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

Жизненный цикл разработки ПО  определяет полный цикл разработки т.е. все задачи включенные в планирование, разработку, тестирование и развертывание программного продукта.

Что вы узнаете:
Процесс жизненного цикла разработки ПО

Циклы разработки ПО

Фазы разработки ПО
1) Сбор и анализ требований
2) Дизайн
3) Программирование и внедрение
4) Тестирование
5) Установка
6) Поддержка
Модели жизненного цикла разработки ПО
1) Водопадная модель
2) V-образная
3) Прототипная модель
4) Спиральная
5) Итеративно -инкрементальная модель
6) Модель большого взрыва
7) Agile модель
Выводы
Рекомендации

Процесс жизненного цикла разработки ПО

Жизненный цикл разработки ПО это процесс который определяет различные этапы включенные в разработку ПО для поставки высококачественного продукта. Этапы SDLC включают все этапы жизненного цикла ПО, т.е. от зарождения до вывода продукта из работы.

Соблюдение рекомендаций SDLC ведет к систематической и дисциплинированной разработке программного обеспечения.

Цель:
Основная цель SDLC поставка высококачественного продукта который соответствует требованиями заказчика.

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

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

Циклы разработки ПО
Этапы SDLC представляют собой процесс разработки ПО.

Внизу представлена диаграмма описывающая основные этапы SDLC

Этапы SDLC
Ниже представлены основные этапы разработки:

  • Сбор и анализ требований
  • Дизайн
  • Программирование
  • Тестирование
  • Установка
  • Поддержка

#1) Сбор и анализ требований


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

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

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

Как только требования ясно представлены и поняты создается SRS (Software Requirement Specification) или Спецификация требований программного обеспечения. Данный документ должен быть тщательно изучен и правильно понят разработчиками и самим клиентом.

#2) Дизайн
На данном этапе, требования зафиксированные в Спецификации используются как исходные данные для создания архитектуры, которая используется при разработке приложения.

#3) Программирование
Программирование начинается как только разработчик получил документ с архитектурой продукта. Дизайн ПО интерпретируется в код. На данном этапе создаются все компоненты ПО.

#4) Тестирование
Тестирование начинается как только завершено программирование и модули готовы для тестирования. На данном этапе, разработанное ПО тщательно тестируется и все найденные баги передаются команде разработчиков для исправления.

Повторное тестирование, регрессионное тестирование производится когда ПО полность соответствует ожиданиями заказчика. Тестировщики сверяют Спецификацию и созданный продукт,  чтоб убедиться что ПО соответствует ожиданиям заказчика.

#4) Установка

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

В случае приемочного тестирования заказчиком, создается копия рабочей среды (моделируются условия) и заказчик вместе с разработчиками проводит тестирование. Если заказчик по итогам тестирования принимает приложение как соответствующее спецификации, то подписываются документы на запуск приложения.

#4) Поддержка
После ввода ПО в эксплуатацию, осуществляется поддержка продукта т.е. если возникает какая-либо проблема, которую необходимо исправить, или необходимо внести какие-либо улучшения, разработчики займутся этим.

Модели жизненного цикла разработки ПО

Модели жизненного цикла разработки ПО это описательное представление процесса разработки ПО. SDLC (Software Development Life Cycle, SDLC) могут иметь различные подходы, но основные этапы и действия остаются одинаковыми для всех моделей.



#1) Водопадная модель


Водопадная модель первая модель из ряда SDLC. Ее также называют линейной последовательной моделью, каскадная моделью.

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

  • Первое, сбор и анализ требований завершен. Когда требования утверждены, далее может начинаться создание системного Дизайна или Архитектуры приложения. Здесь создается SRS (Software Requirement Specification) или Спецификация требований программного обеспечения. То есть Спецификация является итогом сбора требований, и служит основой для создания  системного Дизайна или Архитектуры приложения.
  • На этапе системного Дизайна или Архитектуры приложения, создаются документы которые служат основной для следующего этапа  — Программирования.
  • На этапе Программирования команда разработки пишет код, создает компоненты приложения. Результат работы команды разработки служит для запуска следующего этапа — Тестирование.
  • На этапе тестирования, полученный продукт тщательно тестируется на предмет наличия ошибок. Баги заносятся в системе баг-трекинга (Система отслеживания ошибок) и проходят повторное тестирование после исправления.  Фиксирование багов, повторное тестирование, регрессионное тестирование проводится до тех пор, пока ПО не переходит в рабочее состояние, пока не начинает корректно работать.
  • На этапе Установки, разработанное приложение запускается в эксплуатацию после одобрения заказчиком.
  • Все проблемы возникающие в процессе эксплуатации решаются командой разработки в рамках Поддержки.

Преимущества Водопадной модели:

  • Водопадная модель это простая модель которая может быть легко понята и она одна где все этапы выполняются пошагово.
  • Поставка каждого этапа (результаты) хорошо определены и понятны, это делает проект легко управляемым и не сложным.

Недостатки Водопадной модели:

  • Водопадная модель достаточно трудоемкая и не может быть использована в коротких по длительности проектах, так как в данной модели следующий этап не может быть начат пока не завершен текущий этап.
  • Водопадная модель не может быть использована в проектах у которых неопределенные требования либо где требования изменяются так как данная модель предполагает четкие требования на этапе сбора и анализа требований и все изменения на поздних этапах приведут к увеличению стоимости так как изменения потребуются на каждом этапе.
#2) V-образная  модель


V-образная также известна как Модель Верификации и Валидации. В данной модели Верификация и Валидация идут вместе т.е. разработка и тестирование идут параллельно. V-образная и Водопадная модель похожи за исключением что планирование тестирования и процесс тестирования начинается на ранних этапах в  V-образной  модели.

Этап Верификации:

  1. Сбор и анализ требований
    На данном этапе, собирается вся необходимая информация собирается и анализируется. Верификация заключается в проверке, обзоре требований.
  1. Системный дизайн
    Как только определены требования, начинается проектирования дизайна т.е. архитектура приложения, компоненты продукта. Создается документ с описанием дизайна продукта.
  2. Высокоуровневый дизайн
    Высокоуровневый дизайн определяет архитектуру/дизайн модулей. Он определяет взаимодействие (функциональность) между двумя модулями.
  3. Низкоуровневый дизайн
    Низкоуровневый дизайн определяет архитектуру/дизайн отдельных компонентов.
  4. Программирование
    На данном этапе осуществляется программирование.

    Этап Валидации:

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

2) Интеграционное тестирование
Интеграционное тестирование выполняется используя интеграционные тест кейсы на этапе разработки высокоуровневого дизайна. Интеграционное тестирование — это тестирование интегрированных модулей. Производится тестировщиками.

3) Системное тестирование
Системное тестирование выполняется на этапе разработки Системного дизайна. На данном этапе, вся система проходит тестирование, т.е. весь функционал приложения тестируется.

4) Приемочное тестирование
Приемочное тестирование связано с этапом Анализом требований и производится в рабочей среде заказчика.

Преимущества V-образной  модели

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

Недостатки  V-образной  модели

  • V-образная не подходит проектов в разработка (текущих проектов)
  • Изменение требований на более позднем этапе приведут к повышению издержек.
#3) Прототипная модель разработки ПО


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


Модели-прототипы обладают ограниченными функциональными возможностями и неэффективной производительностью по сравнению с реальным программным обеспечением. Фиктивные функции используются для создания прототипов. Это ценный механизм для понимания потребностей клиентов.

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

Как только завершили процесс сбора требований, в скором времени создается первая версия прототипа которая предоставляется клиенту для оценки (билд).

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

Преимущества Прототипной  модели

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

Недостатки  Прототипной    модели

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

Спиральная модель включает итеративный и прототипный подходы.
Этапы спиральной модели следуют по итерациям. Петли данной модели представляют этапы SDLC (Software Development Life Cycle, Модели жизненного цикла разработки ПО) т.е. ключевой момент — сбор и анализ требований за которым следуют Планирование, Анализ рисков, разработка и оценка качества. Следующая петля это Разработка Дизайна и следующими за ней Разработка и тестирование.


У спиральной модели есть четыре этапа:
Планирование
Анализ рисков
Разработка
Оценка

Планирование:
Этап планирования включает в себя сбор  требований где вся необходимая информация собирается у клиента и документируется. Спецификация требований к программному обеспечению создается на следующем этапе.


Анализ рисков:
На этом этапе выбирается лучшее решение с учетом имеющихся рисков и проводится анализ путем создания прототипа.

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

Разработка:
Как только завершен анализ рисков, следует программирование и тестирование.

Оценка:
Клиент оценивает разработанную систему и планируется следующая итерация.

Преимущества Спиральной  модели

  • Широко применяется анализ рисков через использование прототипной модели.
  • Добавление новых свойств и изменение функционала могут быть выполнены при следующей итерации.

Недостатки  Спиральной    модели

  • Хорошо подходит только для больших проектов.
  • Издержки могут быть высокими так как могут требовать большого количества итераций что может вести к высоким затратам времени для создания финального продукта.
#5) Итеративно инкрементальная модель

Итеративно инкрементальная модель предполагает декомпозицию продукта на небольшие задачи.

Пример: Определен и разработан функционал который будет реализован в рамках итерации. Каждая интеграция проходит этапы Анализ требований, Дизайн, Программирование и Тестирование. Детализированный план не требуется в итерации.

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

Следовательно, продукт увеличивается с точки зрения функций, и после завершения итераций окончательная сборка содержит все функции продукта.

Этапы итеративно инкрементной модели:

  • Начальный этап
  • Этап разработки
  • Этап Создания
  • Переходный этап

Начальный этап
Начальный этап включает в себя сбор требований и определение рамок проекта

Этап разработки
Этап разработки включает в себя разработку рабочей архитектуры проекта которая включает риски определенные на начальном этапе и также учитываются и разрабатываются нефункциональные требования.

Этап Создания
На этапе создания архитектура заполняется кодом, готовым к развертыванию, и создается путем анализа, проектирования, реализации и тестирования функциональных требований.

Переходный этап
На переходном этапе продукт устанавливается в рабочем окружении клиента.


Преимущества итеративно инкрементной  модели

  • Любое изменение требования может быть легко выполнено и не требует затрат, поскольку есть возможность включить новое требование в следующую итерацию.
  • В итерациях идентифицируется и анализируется риск
  • Баги обнаруживаются на ранних этапах
  • Так как продукт декомпозирован на мелкие задачи им легко управлять


Недостатки  итеративно инкрементной    модели

  • Полные требования и понимание продукта необходимы для декомпозиции и разработки.
#6) Модель большого взрыва

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

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

Преимущества модели Большого взрыва

  • Очень простая модель.
  • Не требуется планирования и определенного процесса.
  • Команде разработки предоставлена свобода по созданию продукта как -будто для себя.
  • Так как продукт декомпозирован на мелкие задачи им легко управлять


Недостатки  модели Большого взрыва

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

#7) Agile модель
Agile модель это комбинация итеративной и инкрементальной модели разработки. Данная модель скорее сосредоточена на гибкости во время создания продукта, чем на требованиях.

В модели  Agile продукт разбивается/декомпозируется на малые инкрементальные сборки (билды). Продукт не разрабатывается как сложная система за один подход. Каждая сборка увеличивается количество функций. Каждая последующая сборка строится на предыдущей функциональности.

В Agile итерации называются спринтами. Каждый спринт длится 2-4 недели. В конце каждого спринта владелец продукта проверяет продукт и после его подтверждения, продукт загружается для клиентов.

Обратная связь клиентов учитывается для улучшения продукта и обрабатывается в следующем спринте. Тестирование проводится в каждом спринте для минимизации риска и отказов.

Преимущества модели Agile

  • Это позволяет более гибко адаптироваться к изменениям.
  • Новую функцию можно легко добавить.
  • Удовлетворенность клиентов, отзывы и предложения принимаются во внимание на каждом этапе.


Недостатки  модели Agile

  • Отсутствие документации.
  • Для создания продукта нужны опытные и высококвалифицированные ресурсы.
  • Если клиент не понимает, каким именно он хочет видеть продукт, проект провалится.

#Выводы.

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

Различные модели жизненного цикла разработки программного обеспечения имеют свои плюсы и минусы. Лучшая модель для любого проекта может быть определена такими факторами, как требование (ясное или неясное), сложность системы, размер проекта, стоимость, ограниченные ресурсы и т. д.

Например, в случае неясного требования лучше всего использовать модели Spiral и Agile, поскольку требуемое изменение можно легко внести на любом этапе.

Водопадная модель является базовой моделью, и все остальные модели SDLC основаны только на ней.

Надеюсь, вы получили новые знания о SDLC.

Переход на новую строку в текстовых сообщения Telegram

Новая строка Telegram Bot: при необходимости отправлять информацию через бота Telegram о событиях в других системах возникает необходимость передавать информацию структурировано, с новой строки.

Например, надо сообщить Руководителю отдела продаж о наличии потенциального крупного клиента. Для этого необходимо ему отправить:
-ссылку на сделку в crm
— имя клиента
— телефон клиента
— почту клиента
Как правило для таких целей используются сторонние сервисы, например для amoCRM такую задачу решает сервис Sensei.

Для данных целей можно использовать комбинацию — %0A.
Пример:
1) Отправляем такой URL
https://api.telegram.org/botAPIbotTELEGRAM/sendMessage?chat_id=-idchatTELEGRAM&text=DATA1%0ADATA2%0ADATA3
Как определить chat id Telegram bot ?
2) Получается такой результат


CRM-менеджер

CRM-менеджер

CRM-менеджер это кто?

По мере того как компании проходят проблемный путь с экселя на CRM, становится актуальным вопрос как извлекать выгоду из уже внедренной CRM — системы? Как управлять сотрудниками при помощи CRM- системы?

Тут на помощь приходит CRM-менеджер.

Само название CRM-менеджер скорей всего придумал и стала продавать компания Интроверт — ведущий интегратор amoCRM. Но сам функционал данной позиции существовал и ранее- данную услугу оказывали интеграторы при внедрении amoCRM, иногда данный функционал оставался за руководителем отдела продаж.

 

Лично я при внедрении amoCRM, технической поддержке тоже выполнял функции CRM-менеджера.

 

Функционал CRM-менеджера:

  1. Контроль воронки продаж, правильностью обработки задач, контроль над зависшими сделками.

Работа заключается в том что рассматривается воронка продаж по конкретному менеджеру, его приоритеты в выполнении задач- быстро ли он отрабатывает новые заявки, как быстро отвечает на звонки / письма ключевым клиентам или партнерам. Есть ли у сотрудника зависшие сделки на этапах воронки продаж. Контроль нахождения сделок на том или ином этапе. Здесь функционал скорее руководителя отдела продаж, но и иногда и эту функцию делегируют CRM-менеджеру.

 

2) Контроль за ведением CRM -системы.

Это уже наверно стандартная процедура при внедрении amoCRM через партнеров. Когда настроение все процессы внутри amoCRM, надо помочь людям правильно работать — писать примечания к звонкам, менять статус сделки, заводить контакты. Здесь CRM-менеджер оценивает корректность ведения сделок, контактов и компаний.

 

3) Прослушивание звонков.

Это тоже функционал отдела продаж. Есть даже отдельные компании, которые предоставляют услуги по оценки качества звонков менеджеров по методу CQR (call quality rate — оценка качества звонка). По ссылке можно прочитать про данный метод а здесь можно заказать данную услугу.

Прослушивание звонков имеет важное значение — формируется база знаний, собираются лучшие звонки, из лучших звонков получаются лучшие практики отработки возражений, ведется работа над худшими звонками. Огромное поле для творчества.

 

4) Методами автоматизации можно также следить за следующим:

  • запрет нахождения сделок без задач
  • следить за значениями которые менеджер заносит в поля сделки
  • сигнализировать о просроченной задачи на n минут
  • следить за обработкой пропущенных звонков.
  • сведение норм на нахождения сделки на каждом этапе (статусе) продажи.                         Дополнительно CRM-менеджер может подключать новых сотрудников к amoCRM, заводить им корпоративную почту, подключать к телефонии, следить за корректной работой интеграций. Бюджет и функционал оговаривается при заключении договора на услугу.
Внедрение CRM

Проблемы возникающие при внедрении CRM

Проблемы возникающие при внедрении CRM могут быть разные. CRM — система может вызывать отторжение и негатив у работников. Причины, который озвучивают работники разные — ничего не понятно, неудобно, тут и так работы много а тут еще и неизвестная CRM. Работая на проектах мне удавалось узнать у сотрудников отдела продаж что они думают по поводу внедрения CRM:
— начальник и так  тиран, за все штрафует, а тут еще и CRM.

— мне тут работать надо (искать клиентов, продавать), а тут еще и CRM

— некоторые боялись что работать придется больше.

— я боюсь не разобраться и что-то сделать не так

— все же и так продавалось хорошо

 

Внедрение любой CRM — это внедрение идеи использования CRM в головы людей, пока без этого никуда. У одного крупного интегратора amoCRM есть даже такой курс — “CRM — мышление”.

 

Начальник и так  тиран, за все штрафует, а тут еще и CRM

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

предметом деятельности менеджера является клиент, предметов деятельности руководителя является — сотрудник.

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

 

Мне тут работать надо (искать клиентов, продавать), а тут еще и CRM

Такое возражение мне сказал мужик средних лет. Даже когда в компании начали использовать CRM он все равно некоторые договоренности записывать в свой блокнот. Не вносил примечания, не передвигал сделки по воронке. Об этом докладывали руководителю crm- менеджеры, слушая его звонки просматривая его сделки. Не знаю чем закончилось дело, возможно с ним попрощались.
Сейчас ведение CRM это часть работы менеджера по продажам. По-другому уже нельзя. Чтоб оставаться войну продаж конкурентоспособным необходимо разбираться в CRM — amoCRM, Bitrix24, Pipedrive. CRM помогает продавцу:
— сделать работу предсказуемой, планировать работу

— не забывать про клиента

— как результат — зарабатывать больше.

 

Некоторые боялись что работать придется больше

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

 

Я боюсь не разобраться и что-то сделать не так

Не надо бояться, сейчас каждая популярная CRM -система имеет свою базу знаний, свой канал в ютуб, также есть компании, которые могут помочь с обучением сотрудников как удаленного так и в офисе. Что касается amoCRM то можно воспользоваться либо базой знаний, либо сервисом, который разработали белорусские ребята.

Любую ошибку в CRM можно исправить, кроме отправленного письма клиенту(хотя сейчас  и это можно). Все CRM создаются людьми и для людей, поэтому не бойтесь, если что непонятно, то спрашивайте у коллег либо ищите в интернете.

 

Все же и так продавалось хорошо

Сотрудник работает каждый день, видит что заключаются сделки, поступают деньги на счет. Редко сотрудников допускают к экономике компании, поэтому каждый участник процесса — руководитель, рядовой сотрудник, может обладать своей информацией.

Ну и мнение сотрудников может не совпадать с мнением руководства. Руководство может видеть резервы для роста продаж, на то оно и руководство.

 

Итоги:

  • Проблемы возникающие при внедрении CRM находятся в головах людей. Они вполне решаемы.
  • Плохой начальник на тебя давит без причины — уходи! Не можешь уйти — адаптируйся.
  • CRM становится таким же важным атрибутом продаж как и телефонная трубка. Изучай CRM, работай в CRM!
  • Используй базы знаний, задавай вопросы коллегам.
  • Чтоб зарабатывать деньги, эффективно используй свое время, прикладывай усилия, учись новому.
  • Руководитель, предмет твоего труда — сотрудник отдела продаж. Помогай, обучай, собирай обратную связь. Сотрудники, которые каждый день работают с клиентами могут давать полезные советы по настройке CRM так и ее автоматизации.
chat id telegram

Бот telegram — как узнать chat id telegram?

Я использовал @telegram_bot, у меня стояла задача узнать chat id telegram (id группового чата Telegram) для того, чтобы отправлять уведомления, но я не знал какие надо использовать для этого методы и не нашел ничего полезного в интернете.

Для того чтобы узнать id группового чата telegram (chat id) необходимо:
1) Добавить бота telegram в группу (групповой чат)
2) Получить лист оновлений для вашего бота:

https://api.telegram.org/bot<YourB



OTToken>/getUpdates

Пример:

https://api.telegram.org/bot987654321:abcdefg123_hijkQWZ/getUpdates

3) В результате данной команды, вы можете получить такой ответ:

{«ok»:false,»error_code»:409,»description»:»Conflict: can’t use getUpdates method while webhook is active; use deleteWebhook to delete the webhook first»}

В данном случае необходимо выполнить команду deleteWebhook.
Пример:

https://api.telegram.org/bot<YourBOTToken>/deleteWebhook

Выполнив команду deleteWebhook получаем ответ:

{«ok»:true,»result»:true,»description»:»Webhook was deleted»}

Вебхук удален. Выполняем снова команду getUpdates.

4) Найти сущности, который касаются чата (chat):

{«ok»:true,»result»:[{«update_id»:171132542,
«message»:{«message_id»:9,»from»:{«id»:276136731,»is_bot»:false,»first_name»:»Egor»,»last_name»:»Kazachkov»,»username»:»egorkv»,»language_code»:»en»},«chat»:{«id»:-237214894,»title»:»amoCRM»,»type»:»group»,»all_members_are_administrators»:true},»date»:1551186649,»new_chat_participant»:{«id»:569977248,»is_bot»:true,»first_name»:»Timurtest»,»username»:»timurte_bot»},»new_chat_member»:{«id»:569977248,»is_bot»:true,»first_name»:»Timurtest»,»username»:»timurte_bot»},»new_chat_members»:[{«id»:569977248,»is_bot»:true,»first_name»:»Timurtest»,»username»:»timurte_bot»}]}}]}

Dour Festival

Я всегда любил движ: отправиться в путешествие, пойти на концерт, прогуляться по городу, посетить новую для себя столицу. Но тут про рок-фестиваль, Dour— one love.
Сегодня Dour Festival является одним из самых больших фестивалей в Европе, зародился он в 1989 году, с тех пор мероприятие здорово эволюционировало.
Фестиваль был основан двумя друзьями – Карло ди Антонио и Марком де Фаи.
За время существования фестиваля на его сцене выступали такие исполнители, как Public Enemy, Johnny Hallyday, The Prodigy, Sinik, Pendulum, PNL, Rendez-Vous, Sam Paganini, Sch, Stand High Patrol, Snoop Dogg, CocoRosie, C2C, Starflam.

Dour Fesrival

Каждый год организаторы фестиваля предлагают разнообразную музыкальную программу, фестиваль открыт для разных музыкальных направлений: pop, house, punk, hardcore, rock, post-rock, hip-hop, metal, indus, drum and bass, electro, R&B, reggae, ska, noise, techno. Dour Festival – это:

  • 242 000 посетителей за 5 дней мероприятия
  • семь сцен
  • музыка с 12 дня до 5 утра
  • кемпинг для гостей фестиваля

Dour Fesrival

Первый раз я попал на фестиваль в 2007 году, я окончил школу и был совсем еще зеленый. Белорус в душе, попав на такое мероприятие, испытывает дискомфорт, испытывал его и я. Вокруг тебя масса людей, все говорят на разных языках, представители разных национальностей, жители разных стран, люди с разным цветом кожи, с разными предпочтениями в музыке собираются, чтобы провести вместе 4-5 дней под открытым небом. Сначала это пугает, мне кажется что все мое существо выражало испуг, мне было страшно, к такому масштабу я был не готов. Я не помню, какие группы мне удалось послушать тогда, в далёком 2007-ом, я просто наблюдал и мне этого было достаточно.

Dour Fesrival

Сама подготовка к событию, наверное, начинается за месяц: ограждают территорию, начинают собирать сцены, привозят оборудование, организуют кемпинг (палаточный лагерь).
Цены не самые дешевые, но оно того стоит.

Dour Fesrival

Сервис на европейском уровне, попав туда, при наличии денег вы не останетесь голодными, причем еду можно купить самую разную – фастфуд, натуральная еда (био), еда для веганов и другое. То же самое касается выпивки: пиво, кола, вода, виски и другое. Для тех, кто хочет сэкономить, в пределах досягаемости работают супермаркеты, где можно купить еды по более демократичным ценам.

Dour Fesrival

Часть людей арендует квартиры в самом городе, часть людей спит в своих автомобилях и фургонах. Основная масса ночует в кемпинге. Мне там ни разу побывать не удалось, но по рассказам очевидцев это очень весёлое место (на любителя). Сами можете представить – с 3-4 часов утра вся масса – пьяные и трезвые (последних мало) – возвращается, чтобы отдохнуть.

Dour Fesrival

На территории Dour Festival есть места для отдыха, где можно поспать на креслах-мешках, есть зоны, где можно подзарядить телефон, есть зоны с компьютерами и бесплатным wi-fi. Как-то даже бесплатно раздавали коробочки с зубной щеткой и пастой. Активно развивается тема защиты окружающей среды, так однажды компания Jupiler (бельгийская торговая марка пива) разливало пиво в пластиковые стаканчики, и затем их же обменивала на пиво (10 пустых пластиковых стаканов в обмен на 1 пиво, кажется так). Часто большие компании как coca-cola, redbull или Jack Daniels проводят конкурсы возле своих стендов. Там всегда весело, ребята раздают призы, напитки, во время жары они поливали людей водой и предлагали крем для загара. Все для людей!

Dour Fesrival

Dour Fesrival

Dour Fesrival

Атмосфера дружественная, люди друг другу улыбаются и готовы помочь. Я бы даже сказал, что есть дух “свободы и ответственности”, так как этой большой праздник, существует большая линейка развлечений, и каждый сам выбирает, как ему проводить там время. За здоровьем посетителей следят бригады красного креста. Конечно, при таком наплыве людей (242 000 человек в 2017 году) бывает разное – драки, некоторым от количества выпитого может стать плохо, к сожалению, это неизбежность.

Dour Fesrival

Что запомнилось:
запомнилось выступление группы Sepultura – это бразильская метал-группа.
Я не поклонник метал-направления. Но когда я их услышал, я был очарован. Тот метал, который звучит из колонок, и метал в живом исполнении – это совершенно разные вещи.
От мощи звука захватывало дух, я был впечатлен. В тот момент территория возле Last Arena была наполовину заполнена, но люди все еще прибывали.
Вокалист группы Деррик Грин исполнял песни и держал толпу.

Dour Fesrival

Чистый и энергичный американский рэп от Icecube.

Dour Fesrival

Знаменитые в наших краях Papa Roach.

Dour Fesrival

Замечательно лежать на траве, слегка уставшим, среди друзей, кушать бургер с картошечкой, запивать пивом. Когда ты молод и полон энергии, бесценно танцевать по 3-4 часа до боли в ногах, потом возвращаться под звездным небом домой пешком.
Всегда впечатляло, как небольшая группа людей может сделать из маленького города настоящий бренд. Сам Dour Festival является уже культурным событием и привлекает массы людей для участия, дает толчок развития для региона.

Dour Fesrival

Dour Fesrival

Dour Fesrival

воронка amoCRM

Поиск партнеров в Европе через рассылку и amoCRM

Поиск партнеров, развитие партнерский сети, продажи, экспорт — это те вопросы, которые интересуют каждого собственника, директора или руководителя подразделения. Сегодня я расскажу о кейсе по поиску партнеров в Европе.

Задача — поиск партнеров в Европе.

Клиент — фирма оказывает услуги (Республика Беларусь).

Для начала было сформировано задание на формирование базы.
Было выделено два критерия — это основная деятельность фирмы и локация (место расположения компании).

Поиск осуществлялся стандартными методами:


Поиск в интернете через поисковые системы


Поиск по справочникам


Поиск членов ассоциаций


Поиск в профессиональной социальной сети Linkedin

Данные о компаниях заносились в таблицу google doc.

Таблица содержала следующие столбцы:
Название сделки - техническое поля для импорта в amoCRM, в данное поле записывали название компании.

Полное имя (контакт) - записывали имя контакта, если находили.


Должность (контакт).


Рабочий телефон (контакт).  


Мобильный телефон (контакт).  


Другой телефон (контакт).  


Рабочий email (контакт).  


Название (компания).  


Страна.  


Адрес (компания).  


Сайт компании.  


Рабочий телефон (компания).  


Мобильный телефон (компания).  


Факс (компания).  


Другой телефон (компания).  


Рабочий email (компания).


Facebook - ссылка на профиль компании.


Linkedin - ссылка на профиль компании.

 

На формирование базы ушла 1 неделя. В результате получилась 65 контактов.

Далее был произведен импорт базы в воронку по поиску партнеров в amoCRM.

Воронка в amoCRM содержала следующие этапы:

Новый контакт

Взят в работу

Квалифицирован

Отправлено предложение

Получена обратная связь

Произведен расчет проекта

Также использовался функционал цифровой воронки:

Были настроение автоматические автозадачи для каждого из этапов.

Автоматический перевод сделки на следующий этап при ответе клиента на этапе Отправлено предложение (входящее письмо).

Далее было составлено письмо на французском языке.

Письмо было составлено мной, для того чтобы быть уверенным что письмо написано корректно (смысловая нагрузка, оформление, грамматика) я попросил прочитать письмо и высказать своего мнение у бывшего франкоговорящего коллеги. Получил его обратную связь, внес коррективы и приступил к рассылке.

Условно письмо содержание письма можно описать следующими блоками:

- приветствие;

- рассказ о компании;

- суть обращения, ценность;

- предложение о сотрудничестве;

- описание вариантов сотрудничества;

- заключительная часть;

Opportunité de partenaria
письмо о сотрудничестве

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

Получена обратная связь от 9 компаний, здесь цифра отражает ответы реальных людей плюс автоматические ответы.

В итоге получилось 4 ответа от потенциальных партнеров (этап Проведен расчет КП).

воронка amoCRM
воронка по поиску партнеров в amoCRM

Из них три положительных.

letter

letter

letter

Один отрицательный.

letter

 

Выводы:

  • пишите оригинальные письма, указывайте пользу и ценность предложения.
  • суть письма и ценность можно описать на русском языке, перевести можно через онлайн переводчик, но отправлять письмо в таком виде нельзя. Лучше что письмо прочитал носитель языка, если такого нет, то пусть проверит письмо другой знающий иностранный язык человек.
  • используйте функционал CRM для замера конверсии.
  • будьте креативны: думайте над способами как можно добиться результат от вашей рассылки.