ПРО-продукт
96 subscribers
4 photos
2 files
24 links
Канал для менеджеров проектов, владельцев бизнеса и управленцев, а также всех, кто относит себя к продуктологам и желает создавать качественные web-продукты.
Download Telegram
Когда "сверху" сказали экономить бюджетные деньги, в одном детском саду родился новый формат квитанций 🤦

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

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

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

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

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

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

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

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

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

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

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

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

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

Если перед ними встает выбор сообщить об ошибке или допустить ее – сделают так как написано в ТЗ, т.е. с ошибкой, даже если спокойно могли бы избежать этого. Являются очевидными саботажниками. Могут работать изолированно, например, на проектах по поддержке. В остальных случаях лучше уволить.
👍2🔥1
Продолжаем цикл статей "Отношение к ТЗ в современных ИТ-проектах".
Прошлое убеждение, которое разобрали, звучало как это не оплачивается (не учтено в KPI), значит, и делать не буду.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Получать больше денег и уменьшить количество бюрократии. Заказчики охотно платят за отсутствие геморроя, волокиты и бумажек. Покажите им, что умеете взаимодействовать, быть на связи, нести ответственность и они будут платить вам рублями и преданностью.
👍31🔥1
В серию постов про ТЗ очень подходит 🤣
😁5👍2🤣1
🔰 Получать доход от продажи 1С-разработок на автомате? Не об этом ли мечтает каждый программист 1С?

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

Пятница - отличное время взглянуть на новые возможности!
А это их канал
👨‍💻3🔥1
ПРО-продукт
🔰 Получать доход от продажи 1С-разработок на автомате? Не об этом ли мечтает каждый программист 1С? Фриланс-биржа для 1С-ников DC - это: - Пассивный доход от продажи разработок; - Активный доход от новых заказов; - Диверсификация источников клиентов; - Живые…
В предыдущей статье из цикла "Отношение к ТЗ в современных ИТ-проектах" поработали с убеждением не хочу переделывать без внятного техзадания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А не будет дополнительных пояснений здесь) Мысль достаточно полная, чтобы начать меняться. Действуйте! 🙂
👍3🔥1
🔰 Наблюдения за проектной работой многих команд привели меня к таким заключениям относительно документации:

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

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

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

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

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

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

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

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

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

В. Л. Леви

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

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

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

Находите возможности для регулярных позитивных подкреплений и высказывайте их голосом! 🗣
Писать трудно. Писать постоянно ещё труднее. Ничего и никому не обещая (даже себе) я, пожалуй, расширю круг интересных мне тем и постараюсь как-то уместить их все в одном канале.

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

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

Милая девушка на том конце провода произнесла: "Ой, знаете, только заметила, а почему вы не пользуетесь нашим кешбеком?"

Огонь! Держу их счёт почти год, но о кешбеке только что узнал😁
Не то, чтобы это сильно расстроило, но это же, ёлки-палки, упущенная прибыль🤣

Сначала расстроился, что не смогу купить себе пачку кешбечного сыра (оч. люблю).

Потом обрадовался, когда узнал, что это всего 3 процента (мощь!) И таки-купил себе сыр на свои кровные🤣

В общем бесплатный сыр сами знаете где. И точка.