#Автоматизация #1С
Сезон отпусков закончился. Пришло время активной онлайн-торговли - золотая пора для совершения рывков в развитии продаж 🔥📈

Коммерсантам нужны удобные инструменты для управления продажами и сокращения издержек. И желательно одновременно!

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

В то же время рынок не дремлет. Появляются новые онлайн площадки для сбыта. Если все мы уже привыкли к Ozon, Wildberries, Яндекс.Маркет, СберМегаМаркет, то сколько их еще - всяких поменьше, но тоже способствующих росту продаж и отнимающих ресурсы на их содержание и актуализацию.

Встает вопрос, кто будет поддерживать весь этот зоопарк?

⚠️ Слава разработчикам и программистам, которые давно решили этот вопрос. Вам осталось только выбрать подходящий инструмент. Предлагаю краткий обзор 3-х таких решений, которые позволят вам управлять онлайн площадками прямо из привычного интерфейса 1С.

Их общие преимущества:

✔️ Управление продажами на маркетплейсах из одного окна;
✔️ Нет необходимости в увеличении штата персонала, т.к. все может делать один оператор;
✔️Максимальная автоматизация типовых процессов: выгрузка товаров и остатков, загрузка заказов в 1С, актуализация информации и прочие рутинные операции.

🟢 Управление онлайн торговлей. Интеграция 1С с маркетплейсами: Вайлдберриз, Озон, СберМегаМаркет, Яндекс.Маркет, АлиЭкспресс, другими сервисами, а также интеграции с любыми поставщиками

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

Поддерживаются обмены по схемам FBS, FBO и ЭДО. Работает с конфигурациями:

▪️Управление торговлей 11,
▪️Комплексная автоматизация 2.0,
▪️ERP Управление предприятием 2.0

🟢 Модули интеграции с маркетплейсами (WILDBERRIES + ЯНДЕКС МАРКЕТ) по схеме FBS для УТ 11, КА 2, ERP 2

Расширения обеспечивают работу с личными кабинетами маркетплейсов WILDBERRIES и ЯНДЕКС.МАРКЕТ на принципах FBS. Для разработки характерны простой запуск и удобство использования. Купив решение, вы сможете увеличить скорости сборки и наклейки стикеров на заказы при больших объемах отгрузок.

Код разработки полностью открыт и позволяет самостоятельно проводить любые необходимые изменения.

🟢 Интеграция 1С с маркетплейсами (Ozon, Wildberries). Обычные формы

Решение встраивается в типовую конфигурацию УТ10.3, КА 1.х, УПП 1.3 или самописные конфигурации.

Программа осуществляет выгрузку карточек товаров в ОЗОН/Wildberries, загрузку и синхронизацию ранее загруженных карточек с номенклатурой в 1С, гибкую настройку синхронизации по номенклатуре, характеристикам, сериям и единицам измерения, а также загрузку отправлений ОЗОН/ Сборочных заданий Wildberries и создание на их основании документов в 1С и управление статусами отправлений ОЗОН/ Сборочных заданий Wildberries.

А вы успели подготовиться к активной осенней торговле? Какие решения используете? Пишите в комментариях!

#ПсихологияОбщения

...Начало поста

7️⃣ Проверьте предложение до отправки и после. Если заметили, что ваш Т9 где-то накосячил - исправьте. Не исключено, что искусственный интеллект решил восстать против вас именно сейчас.

- Да вот не понятно, трели выжила, то ли до последнего боролась за него

- Бля, здравствуйте!
В продолжение предыдущего письма...

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

Но что если пойти обратным путем? - попробовать обработать ее здесь, на входе чуть более качественнее, чем обычно? Ведь какой смысл в коммуникации, если тебя не понимают?

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

Давайте применим этот принцип к нашему человеческому взаимодействию?

И всякий раз, когда будем отправлять сообщение адресату, "предобработаем" его - подумаем, над его формой и содержанием.

#УправлениеПроектами #Формализация

🔰 Поговорим о так называемом "Плане коммуникаций".

План коммуникаций - документ, рекомендуемый практически всеми фреймворками по управлению проектами.

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

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

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

Что нужно сделать, чтобы составить хороший план:

✅ Обозначить основной канал коммуникации: скайп, телеграм, слак, что-то еще.

✅ Обозначить участников коммуникации.

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

✅ Ознакомить с готовым документов всех участников и закрепить на видном месте.

Заметка из жизни о том, куда уходит время
Был у меня на проекте один верстальщик. Толковый очень парень, но, что называется "весь в себе". Дизайнер пишет верстальщику вопрос. Тот читает его (видно в мессенджере, что сообщение прочитано), но не отвечает. Дизайнер при этом ожидает ответа, т.к. скоро должен отойти по личным делам, а ответ позволит ему быстро доделать начатую работу и передать результат дальше. Получается, что верстальщик, который, как оказалось, не посчитал вопрос важным, задерживает проект. И сам того не осознает! Дизайнер простаивает и ох**вает от безразличия демотивируется, уходит ценный ресурс - время.

Налицо разница в ответственности и подходах к делу. Чтобы ее нивелировать нужно заложить такие ситуации в план, обозначить принципы реакции и отслеживать как это работает на практике. При необходимости - давать взбучку за несоблюдение.

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

Стоит ли говорить, что проект все это время пробуксовывал.

Стандартные косяки в коммуникациях, которые необходимо учитывать в плане:
1. Отсутствие какой-либо реакции на сообщения.
2. Долгая реакция на сообщения.
3. Боязнь "потревожить" человека напрасно.
4. Флуд в коммуникациях - переизбыток сообщений без полезной нагрузки.

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

Само собой, что вам нужно не только декларировать открытость, но и действовать самому в рамках этого принципа!

#Формализация #Документация

#Продажи #Маркетинг
🔰 Правильная оценка проекта в IT и подача КП

Как обычно происходит оценка проекта в IT?

ТЗ от клиента дают на осмотр специалисту / старшему специалисту / руководителю проектов. Он прикидывает объем трудозатрат "за всех" и сообщает менеджеру грубую оценку. Менеджер накидывает на эту стоимость некий фирменный коэффициент и получает сумму, которую озвучивает клиенту.

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

Правильный подход к оценке должен состоять из следующих этапов.

✅ Выяснить трудозатраты всех специалистов, которые будут участвовать в производстве проекта: дизайнеры, программисты, тестировщики и т.д.

✅ Заложить суммы бонусов производственникам за успешное выполнение проекта в срок. Позже эти суммы закладываются в KPI.

✅ Учесть риски на сюрпризы в ТЗ, хотелки и "забывалки" клиента. Такие риски могут составлять до 50% стоимости проекта.

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

✅ Учесть управленческую надбавку за менеджмент проекта.

✅ Увеличить сумму на величину налогов.

Полученную сумму ещё рано демонстрировать клиенту.

Продолжение сегодня... 👇

#Продажи #Маркетинг
... начало статьи выше ☝️

Чтобы она не казалась неподъемной, функционал проекта стоит разбить на категории. Условно это могут быть "min", "standard" и "platinum" комплекты.

✔️ В варианте "min" реализация проекта представляет собой минимально работающий функционал только с самым необходимым набором базовых функций.

✔️ Вариант "standard" содержит функции, достаточные для комфортной работы пользователей, но без излишеств, "бантиков" и супер удобств, характерных для варианта "platinum".

✔️ Вариант "platinum" - это all inclusive в мире IT. Полная цена за все функции продукта обозначена тут.

Но и это ещё не всё.

⚡️ Фишка: в отдельном разделе КП представьте клиенту те функции продукта, которые он не заказывал, но которые ему могут быть полезны!

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

Это одновременно и увеличит ваш потенциальный доход и снизит на своем фоне общую стоимость продукта по ТЗ.

❓ Как понять, какие функции включать в состав "platinum" комплекта? Ведь ваша задача как руководителя - максимизировать прибыль с продукта и принести клиенту максимальную пользу. При этом, крайне желательно, не потерять клиента еще на этапе оценки)

Разбейте ТЗ на функциональные блоки. И попросите клиента дать каждому из блоков приоритеты. Воспользуйтесь MOSCOW приоритезацией - это удобно!

Если вы ещё не встречались с этим, то позже я напишу, что это такое. Сейчас просто знайте, что функционал, который клиент обозначит как C (could have) и W (would have) надо включать в комплект "platinum".

Передайте получившееся КП клиенту, но не молча!

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

Продолжение сегодня... 👇

#Продажи #Маркетинг
Часть 1
Часть 2

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

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

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

Кратко подведем итоги:

✅ Разбиваем ТЗ клиента на функциональные блоки.

✅ Просим сделать его приоритезацию каждого блока.

✅ Проводим внутреннюю оценку.

✅ Раскладываем функционал по КП на "min", "standard" и "platinum" комплекты.

✅ Добавляем upsale-функционал в наше предложение.

✅ Выкладываем КП на сайт или шарим для совместного доступа.

✅ Сопровождаем звонком или встречей для защиты и заключения сделки.

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

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

Пользуйтесь этой схемой и пусть ваши проекты будут всегда прибыльны, а заказчики довольны!

Пишите в комментариях, какие советы из статьи вам показались полезными и что считаете неприемлемым.

Подискутируем🙂

#Текущее

Привет! 🙂

Последнюю неделю активно погружен в запуск большого проекта, связанного с фриланс-активностью для 1С-программистов. Времени писать в канал практически нет, простите🙈

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

〰️〰️〰️

3.1 Недопустимы публикации, содержащие:
3.1.1 Ссылки на любые информационные ресурсы и материалы, не соответствующие предмету публикации;
3.1.2 Искусственно обусловленное ограничение контента с побуждением получить недостающую информацию на другом информационном ресурсе;
3.1.3 Рекламу сторонних ресурсов или призывающие воспользоваться товарами или услугами определенной компании, физического лица или круга лиц;
3.1.4 Явные или скрытые отзывы на компании, физических лиц, места, события, действия;
3.1.5 Негативное отношение автора к предмету публикации и созданные исключительно с целью критики, если они не подкреплены достаточно полным всесторонним анализом темы и основаны исключительно на личном мнении автора.

〰️〰️〰️
В частности интересует:
1. Не кажется ли вам, что какие-то пункты являются частными случаями других?
2. Можно ли по-вашему как-то упростить формулировки, но при этом не упустить ничего важного из описанного?

Буду рад вашему мнению в комментариях!

Знаю, вы снова меня потеряли!

Я здесь. И сегодня мы открыли регистрацию программистов 1С на портале https://drip-center.ru

За последние дни было многое сделано:

✅ Разработана система регламентов

✅ Устранены замеченные ошибки в работе личного кабинета - в моем журнале регистрации ошибок сегодня юбилей - 50 штук😁

✅ Отлажен процесс регистрации

И еще многое предстоит!

Продолжаем пилить страницу материала - наделяем ее свойствами, которые будут понятны программистам при публикации решений и которые необходимы для построения классного каталога, удобного для поиска и пользователей!

Работы много, работа кипит. Возможно, скоро покажу вам дизайн. Или не покажу :) Пока не решил.

Не теряйте!

Кстати, если вы программист и у вас есть под подушкой решения, которые можно продавать, регистрируйтесь здесь: https://drip-center.ru/expert-1c/ и продавайте!

Инфостарт (программисты 1С знают, о чем я) уже порядком всем надоел, а здесь вы сможете начать с нуля. Конкуренции с коллегами пока нет. Кто будет первым - тот снимет все сливки🫵

Пока открыли регистрацию только для 100 человек - будем отлавливать косяки, которые еще не отловили и оперативно их исправлять. И только первым 100 людям дадим специальные бейджы 🏷 - так все заказчики будут знать, что вы первые.

Короче, попробуйте!

Когда "сверху" сказали экономить бюджетные деньги, в одном детском саду родился новый формат квитанций 🤦

А где-то тем временем идёт цифровизация😭

А вы тоже думали, что задачи бизнеса решает компания? В прошлой статье из цикла "Отношение к ТЗ в современных ИТ-проектах" мы разобрали, что практику переноса ответственности стоит сокращать, а сегодня разберем еще одно популярное убеждение, приводящее к конфликтам:

🔰 Это не оплачивается (не учтено в KPI), значит, и делать не буду

Что сделать с точки зрения психологии?
Осознать, откуда в компании появляются деньги. Понять, за что действительно платит клиент (нет, не за работу по ТЗ). Постигнуть ценность таких понятий как взаимопомощь, взаимовыручка, профессиональный долг. Определить свою нравственно-этическую позицию в компании. Подумать над тем, когда компания получает больше пользы от вас: когда вы создаете ей проблемы или когда решаете проблемы? Подумать, в каком из этих случаев будет расти ваше вознаграждение и как можно повлиять на него.

Что сделать физически?
Продолжать так же качественно делать свою работу (как и сейчас), но уже с осознанием того, что я описал с точки зрения психологии. Если вы напрямую работаете с заказчиком, например, вы – фрилансер, то доходчиво объяснить клиенту, за что он вам платит и как следует описать процесс изменения требований в единой связи с их оплатой, убедиться, что вас поняли. Кстати, если вы до сих пор не знаете, за что вам платит клиент, спросите прямо у него – узнаете много интересного.

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

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

Что сделать управленчески?

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

✅ Обеспечить прозрачность и выполнимость таких процессов. Изменить KPI по рекомендациям задачи бизнеса решает компания/менеджмент (не я лично).

✅ Отправить всех методистов, постановщиков и аналитиков на тренинги по написаниям ТЗ.

✅ Выявить и уволить людей, допускающих выполнение заведомо некорректных требований в ТЗ без их предварительной верификации.

Дополнительные пояснения
Часто за формулировками «это не оплачивается» стоит банальная лень и страх изменений. Обычно у таких специалистов, все в действительности хорошо – оклад их устраивает, а больше денег им и не нужно.

Перестраиваться они не хотят, а потому избегают любых попыток привлечь себя к анализу требований. Такие сотрудники 100% формалисты и бюрократы. На вопрос «чей косяк?» они всегда сошлются на «убогое ТЗ», «криворуких постановщиков» и трудовой договор. Они редко признают свои ошибки, т.к. считают, что их допустил кто угодно, но не они.

Если перед ними встает выбор сообщить об ошибке или допустить ее – сделают так как написано в ТЗ, т.е. с ошибкой, даже если спокойно могли бы избежать этого. Являются очевидными саботажниками. Могут работать изолированно, например, на проектах по поддержке. В остальных случаях лучше уволить.

Продолжаем цикл статей "Отношение к ТЗ в современных ИТ-проектах".
Прошлое убеждение, которое разобрали, звучало как это не оплачивается (не учтено в KPI), значит, и делать не буду.

Сегодня у нас такое:

🔰 Не хочу переделывать без внятного техзадания

Что сделать с точки зрения психологии?

Тут обычно подразумевается, что кто-то (обычно заказчик, если работаете напрямую, или аналитик - в компании) должен предоставить это техзадание автору убеждения.

Подать, так сказать, на блюдечке с голубой каемочкой.
Чтобы понять всю абсурдность такой позиции достаточно представить как врач, после неудачных попыток вылечить вас, просит сделать для него (более) внятное ТЗ. А если, в автосервисе от вас вдруг попросят такое ТЗ, как вам? Понравится?

Ваши опасения вполне понятны. Но они бы не вылились в переделки, если бы изначально вы провели более качественную диагностику проблемы и верификацию требований. Таким образом, если перед нами замаячило такое убеждение, то в 95% случаев мы допускаем ошибку раньше – скорее всего, спешим быстрее начать работу, не проявляем достаточной вовлеченности при выявлении проблемы, погружении в задачу, описании конечного результата. Допускаем промахи во взаимодействии с заказчиком (постановщиком), не внимательны к деталям.

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

Что сделать физически?
Если вы – исполнитель ТЗ, то нужно активнее участвовать в сборе требований и их верификации и формализации. Об этом я уже писал выше.

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

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

Что сделать управленчески?
Организовать совместную работу над ТЗ аналитиками и тестировщиками. Предполагается, что одновременно с написанием ТЗ ведется подготовка сценариев тестирования и все это передается заказчику на ознакомление. Смысл в том, что хороший сценарий тестирования обычно достаточно нагляден. Если его передать заказчику перед началом работ, то ему будет проще оценить, соответствуют ли его желания описаниям. А у разработчиков будет меньше вариантов ошибиться. В рамках управленческих подходов следует также зафиксировать процедуры совместной работы в административных регламентах компании. Рассмотреть переход на agile.

Дополнительные пояснения
Заказчик имеет полное право не понимать, не уметь или не хотеть делать для вас ТЗ. Ему важен конечный результат, который закроет проблемы его бизнеса. Если принять это утверждение как данность, то перед вами откроются следующие возможности:

✅ Быть на голову выше своих конкурентов, работающих по схеме «Дайте ТЗ».

Вместо этого стоит перейти на схему:
проблема (ставит заказчик) – анализ ( делаете вы) – предложения (вы) – решение (вы) + постоянное взаимодействие с получением обратной связи и корректировка действий.

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

В серию постов про ТЗ очень подходит 🤣

🔰 Получать доход от продажи 1С-разработок на автомате? Не об этом ли мечтает каждый программист 1С?

Фриланс-биржа для 1С-ников DC - это:
- Пассивный доход от продажи разработок;
- Активный доход от новых заказов;
- Диверсификация источников клиентов;
- Живые клиенты и никакого хейта от завистников;

Пятница - отличное время взглянуть на новые возможности!
А это их канал

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

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

🔰Ответственность за ТЗ на заказчике (на бизнесе), т.к. он его подписал

Что сделать с точки зрения психологии?

Уверен, что бизнесы, которые не поймут, что бюрократия – это зло, скоро умрут. Говоря о бизнесе, я конечно же, имею ввиду менеджмент и сотрудников, стоящих за ним.

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

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

О чем это я и как это связано с ИТ? А это об уровне зрелости компании, о понимании тонких материй. Это не про то, как зачеркнуть ценник и продать куртку «со скидкой», а когда у нее сломается молния развести руками. Не про то, как поставив на весы лишний грузик, обвесить на картошке и заработать рубль здесь и сейчас «на дурака». Это про игру в долгую.

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

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

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

Что сделать физически?

Спросить у клиента, что его действительно не устраивает и доделать работу. В моем опыте часто бывает такое, что клиенту не хватает какой-то мелочи, но при этом программист встает в позу и «принципиально» не дорабатывает на 99% выполненную программу. К чему такая принципиальность? Просто сделайте этот 1% работы и выставьте дополнительные деньги к следующему счету.

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

Что сделать управленчески?

✅ Перевести внутренние процессы согласований в электронную форму.

✅ Сместить фокус с бумажек на СО-трудничество, поставить во главу угла взаимодействие вместо формальностей.

✅ Научить аналитиков и прочих постановщиков визуализировать будущие результаты работы (прототипы, мокапы) – они, обычно, более внимательно изучаются заказчиками.

Хороший прототип, особенно динамический, может покрыть в себе до 90% ТЗ. Остальное покрывается описанием процессов в каких-нибудь понятных нотациях (типа BPMN) и верхнеуровневыми (небольшими) ТЗ.

Дополнительные пояснения

А не будет дополнительных пояснений здесь) Мысль достаточно полная, чтобы начать меняться. Действуйте! 🙂

🔰 Наблюдения за проектной работой многих команд привели меня к таким заключениям относительно документации:

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

▪️ Чем дольше заказчиком ведется производство и/или утверждение документации, тем быстрее теряется мотивация к работе непосредственно над проектом.

▪️ Если у проекта поменяются ответственные лица, то в документации все равно никто не разберется, а тот, кто будет разбираться – сделает это "задорага", в том смысле, что изрядно помотает нервы исполнителю.

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

▪️ Объемные ТЗ часто содержат противоречивые требования и сильно ограничивают выбор подрядчика в способах реализации.

Просто на подумать ℹ️

Продолжение цикла статей "Отношение к ТЗ в современных ИТ-проектах". Ранее проработали ответственность за ТЗ на заказчике (на бизнесе), т.к. он его подписал. Сегодня работаем с убеждением:

🔰 Никто и никому ничего не должен

Что сделать с точки зрения психологии?
Попытаться осознать это стихотворение. Хотя не надо пытаться. Вы ведь вовсе не должны.

Ну, когда же наконец я пойму: я не должен ничего никому, я не должен ничего никому, в том числе и себе самому.
Спи спокойно, мой Господи-Боже, обнимая вселенскую тьму, никому ничего ты не должен, в том числе и себе самому.
И когда ты молитву услышишь, медитацию, то или се, ты и волосом не поколышешь, потому что не должен, и все.

В. Л. Леви

Что сделать физически?
Уволиться. С такими убеждениями начальник не должен платить вам зарплату, а вы не должны работать на него. Я уж совсем не говорю о ТЗ – это за гранью понимания.

Что сделать управленчески?
Проводить более тщательный отбор кандидатов на работу.

Тема мотивации удаленных сотрудников стоит отдельной книги. Сегодня затрону ошибку, которая встречается в практике управления коммуникациями между PM (PO) и удаленными программистами ⚠️

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

Находите возможности для регулярных позитивных подкреплений и высказывайте их голосом! 🗣