#Документация #Формализация
Сочинил я, однажды, для компании клиента вот такую политику качества:
☑️ Политика по качеству:
1. Клиент приносит компании прибыль. Внимание и искренняя забота о нем увеличивают прибыль, а равнодушие и халатность уменьшают ее.
2. Мы не вступаем в споры с клиентами.
3. Мы не перебиваем клиента.
4. Мы слушаем клиента и фокусируемся на его потребностях.
5. Мы предлагаем клиенту разные варианты решений.
6. Мы даем клиенту ощущение понимания, важности, безопасности.
7. Мы общаемся с клиентом простым и понятным языком без «технаризмов».
8. Мы признаем свои ошибки и принимаем меры для их устранения.
☑️ Критерии высокого качества обслуживания клиентов (KPI):
- Получение повторных заказов от одного клиента и их регулярность.
- Новые заказы от клиентов, пришедших по рекомендации.
- Хорошие отзывы о специалистах.
Да, вот такая короткая. Всего 8 пунктов и 3 дополнительных критерия для учета в KPI.
🆕 В результате внедрения этой политики и перманентного автоматизированного контроля за ее соблюдением, ТОПы и я наблюдали интересные эффекты:
1. В течение 3х месяцев уволились 7 менеджеров-консультантов.
2. За это же время на их место пришли только 5 новых.
3. Выросло число повторных заказов на 34%.
4. Совокупные затраты на ФОТ менеджерам сократились на 23%.
5. Прибыль компании за этот же период выросла на 12,2%.
Во исполнение этой политики были внедрены методички по общению с клиентами, проведены работы по изменению корпоративной CRM, где дополнительно учитывались новые параметры сделок, а также была кардинально изменена система премирования консультантов.
🆕 Самым важным я считаю то, что согласно новым KPI, менеджеры по продажам получили новую, прогрессивную шкалу получения бонусов, которая учитывала повторные продажи и рекомендации.
📈 Выглядело это так:
Первая сделка.
- Консультант получает 10%.
- Если клиент пришел по рекомендации, то 20%.
Вторая – 25%.
Третья – 30%.
Четвертая и последующие – 40%.
⚠️ При этом бонус менеджеру причитался только с той части суммы сделки, которая проходила сверх установленной бизнесом гарантированной маржинальности.
Маржинальность сделки устанавливал собственник в CRM, а себестоимость просчитывалась менеджером. Таким образом, каждый менеджер теперь видел, следующую информацию при заведении сделки в систему:
1. Себестоимость сделки. Ее считает сам менеджер. Это сумма всех затрат, которые понесет компания на обслуживание заказа. Эти затраты заранее известны. Допустим, они составят условные 100 000 рублей.
2. Управленческая маржа. К себестоимости система автоматом накручивала так называемую управленческую маржу. Это процент, который задавал собственник. Допустим, процент был равен 40. Тогда менеджер на экране видел цифру 140 000 рублей. Управленческая маржа, гарантировала собственнику прогнозируемую рентабельность любой сделки.
3. Менеджерская надбавка. Чтобы менеджеру заработать свои 10-40% ему нужно было прибавить к этой сумме еще какое-то произвольное число. Теоретически оно могло быть бесконечно большим, т.к. компания оказывала услуги консалтинга в области ИТ. На практике ограничениями этой сумме служили лишь установки в голове менеджера, а также лояльность и платежеспособность клиента.
4. Бонус менеджера. Допустим, менеджер понимал, что клиент готов заплатить еще 100 000 рублей. Тогда он вводил эту сумму в специальное поле и видел, сколько денег он получит за эту сделку, бонусом к своему окладу. При условии, что эта первая сделка клиента, менеджер точно знал, что он получит 10 000 рублей. Если это четвертая или следующая сделка, то он получит сразу 40 000 рублей.
Таким образом, по данным нашего примера, первая сделка выходила:
Для клиента – 240 000 рублей.
Для менеджера – 10 000 рублей.
Для бизнеса – 130 000 рублей = 240 000 – 100 000 (себестоимость) – 10 000 (бонус менеджера)
❗️Важным условием в данной схеме мотивации было то, что сделка считалась новой, если клиент не заказывал услуги повторно в течение определенного собственником периода. Получилась эдакая накопительная система бонусов по аналогии с супермаркетами. Год не покупал – все сгорело.👇
Сочинил я, однажды, для компании клиента вот такую политику качества:
☑️ Политика по качеству:
1. Клиент приносит компании прибыль. Внимание и искренняя забота о нем увеличивают прибыль, а равнодушие и халатность уменьшают ее.
2. Мы не вступаем в споры с клиентами.
3. Мы не перебиваем клиента.
4. Мы слушаем клиента и фокусируемся на его потребностях.
5. Мы предлагаем клиенту разные варианты решений.
6. Мы даем клиенту ощущение понимания, важности, безопасности.
7. Мы общаемся с клиентом простым и понятным языком без «технаризмов».
8. Мы признаем свои ошибки и принимаем меры для их устранения.
☑️ Критерии высокого качества обслуживания клиентов (KPI):
- Получение повторных заказов от одного клиента и их регулярность.
- Новые заказы от клиентов, пришедших по рекомендации.
- Хорошие отзывы о специалистах.
Да, вот такая короткая. Всего 8 пунктов и 3 дополнительных критерия для учета в KPI.
🆕 В результате внедрения этой политики и перманентного автоматизированного контроля за ее соблюдением, ТОПы и я наблюдали интересные эффекты:
1. В течение 3х месяцев уволились 7 менеджеров-консультантов.
2. За это же время на их место пришли только 5 новых.
3. Выросло число повторных заказов на 34%.
4. Совокупные затраты на ФОТ менеджерам сократились на 23%.
5. Прибыль компании за этот же период выросла на 12,2%.
Во исполнение этой политики были внедрены методички по общению с клиентами, проведены работы по изменению корпоративной CRM, где дополнительно учитывались новые параметры сделок, а также была кардинально изменена система премирования консультантов.
🆕 Самым важным я считаю то, что согласно новым KPI, менеджеры по продажам получили новую, прогрессивную шкалу получения бонусов, которая учитывала повторные продажи и рекомендации.
📈 Выглядело это так:
Первая сделка.
- Консультант получает 10%.
- Если клиент пришел по рекомендации, то 20%.
Вторая – 25%.
Третья – 30%.
Четвертая и последующие – 40%.
⚠️ При этом бонус менеджеру причитался только с той части суммы сделки, которая проходила сверх установленной бизнесом гарантированной маржинальности.
Маржинальность сделки устанавливал собственник в CRM, а себестоимость просчитывалась менеджером. Таким образом, каждый менеджер теперь видел, следующую информацию при заведении сделки в систему:
1. Себестоимость сделки. Ее считает сам менеджер. Это сумма всех затрат, которые понесет компания на обслуживание заказа. Эти затраты заранее известны. Допустим, они составят условные 100 000 рублей.
2. Управленческая маржа. К себестоимости система автоматом накручивала так называемую управленческую маржу. Это процент, который задавал собственник. Допустим, процент был равен 40. Тогда менеджер на экране видел цифру 140 000 рублей. Управленческая маржа, гарантировала собственнику прогнозируемую рентабельность любой сделки.
3. Менеджерская надбавка. Чтобы менеджеру заработать свои 10-40% ему нужно было прибавить к этой сумме еще какое-то произвольное число. Теоретически оно могло быть бесконечно большим, т.к. компания оказывала услуги консалтинга в области ИТ. На практике ограничениями этой сумме служили лишь установки в голове менеджера, а также лояльность и платежеспособность клиента.
4. Бонус менеджера. Допустим, менеджер понимал, что клиент готов заплатить еще 100 000 рублей. Тогда он вводил эту сумму в специальное поле и видел, сколько денег он получит за эту сделку, бонусом к своему окладу. При условии, что эта первая сделка клиента, менеджер точно знал, что он получит 10 000 рублей. Если это четвертая или следующая сделка, то он получит сразу 40 000 рублей.
Таким образом, по данным нашего примера, первая сделка выходила:
Для клиента – 240 000 рублей.
Для менеджера – 10 000 рублей.
Для бизнеса – 130 000 рублей = 240 000 – 100 000 (себестоимость) – 10 000 (бонус менеджера)
❗️Важным условием в данной схеме мотивации было то, что сделка считалась новой, если клиент не заказывал услуги повторно в течение определенного собственником периода. Получилась эдакая накопительная система бонусов по аналогии с супермаркетами. Год не покупал – все сгорело.👇
☝️Работало это отлично, а главное ликвидировало кучу проблем:
1. У собственника перестала болеть голова за то, что менеджеры делали скидки клиентам любой ценой. Обычно эта цена была прибылью, – а иногда и убытком! – компании. Сейчас собственник получал гарантированную маржинальность сделки, которой он сам мог управлять.
2. Менеджеры стали дорожить клиентами, т.к. их доход возрастал в перспективе, а не просто зависел от суммы сделки как ранее.
3. Консультанты стали сами активно напоминать клиентам об акциях, новых услугах, обновлениях ПО и прочих прелестях, на которых можно заработать, совершив еще одну сделку. Терять наработанные проценты никто не хотел.
4. Так как в мотивации теперь были учтены клиенты, пришедшие по рекомендациям, то менеджеры начали спрашивать у своих клиентов, кому бы еще компания могла бы оказать свои услуги, чего ранее не наблюдалось. Следствием этого стало активное и бесплатное пополнение клиентской базы новыми «сарафанными» клиентами.
5. Компания стала пополнять сайт новыми отзывами о своей работе, т.к. у консультантов появилась мотивация их собирать – за каждый отзыв менеджер получал дополнительно 1 000 рублей премии. Также это косвенно сыграло на СЕО и лояльность.
6. Консультанты, фактически, теперь могли сами регулировать свой заработок. Новая система мотивации поощряла их искать пути для снижения себестоимости проектов – тогда они могли накрутить себе больше менеджерской надбавки.
7. В коллективе наступила здоровая атмосфера. Появилась правильная конкуренция. Менеджеры, постоянно делающие клиентам скидки, пересмотрели свои привычки и, если и продолжали их делать, то только за счет собственных надбавок. Кто не смог перестроиться (прим. халявщики) – уволился.
✅ Вот так вот достаточно незамысловато и одновременно эффективно мы навели порядок в делах фирмы. А добились этого за счет правильных установок и смещения акцентов в сторону интересов клиентов и бизнеса.
1. У собственника перестала болеть голова за то, что менеджеры делали скидки клиентам любой ценой. Обычно эта цена была прибылью, – а иногда и убытком! – компании. Сейчас собственник получал гарантированную маржинальность сделки, которой он сам мог управлять.
2. Менеджеры стали дорожить клиентами, т.к. их доход возрастал в перспективе, а не просто зависел от суммы сделки как ранее.
3. Консультанты стали сами активно напоминать клиентам об акциях, новых услугах, обновлениях ПО и прочих прелестях, на которых можно заработать, совершив еще одну сделку. Терять наработанные проценты никто не хотел.
4. Так как в мотивации теперь были учтены клиенты, пришедшие по рекомендациям, то менеджеры начали спрашивать у своих клиентов, кому бы еще компания могла бы оказать свои услуги, чего ранее не наблюдалось. Следствием этого стало активное и бесплатное пополнение клиентской базы новыми «сарафанными» клиентами.
5. Компания стала пополнять сайт новыми отзывами о своей работе, т.к. у консультантов появилась мотивация их собирать – за каждый отзыв менеджер получал дополнительно 1 000 рублей премии. Также это косвенно сыграло на СЕО и лояльность.
6. Консультанты, фактически, теперь могли сами регулировать свой заработок. Новая система мотивации поощряла их искать пути для снижения себестоимости проектов – тогда они могли накрутить себе больше менеджерской надбавки.
7. В коллективе наступила здоровая атмосфера. Появилась правильная конкуренция. Менеджеры, постоянно делающие клиентам скидки, пересмотрели свои привычки и, если и продолжали их делать, то только за счет собственных надбавок. Кто не смог перестроиться (прим. халявщики) – уволился.
✅ Вот так вот достаточно незамысловато и одновременно эффективно мы навели порядок в делах фирмы. А добились этого за счет правильных установок и смещения акцентов в сторону интересов клиентов и бизнеса.
👏2
При сотрудничестве с программистами важно договориться «на берегу» о правилах взаимодействия.
Предлагаю вам свод таких правил, накопленных за годы руководства проектами. Какие-то пункты вам могут показаться очевидными, какие-то вызовут интерес или отторжение, некоторые – удивление, но все они, так или иначе, отработаны на практике и проверены в боях. Так что можете смело адаптировать их под себя и пользоваться.
☑️ Соглашение о сотрудничестве:
Данное соглашение призвано установить доверительно-деловой климат при совместной работе над проектами и решением сопутствующих задач.
1. Если специалист понимает, что задача поставлена некорректно, то он ее уточняет до степени взаимно-однозначного соответствия с заказчиком.
2. Специалист предлагает возможные варианты решения, которые могут быть полезны для проекта, но упущены из поля видимости заказчиком.
3. Специалист соблюдает рекомендуемые методики проектирования, уделяет внимание чистоте и эргономике интерфейсов, придерживается стандартов разработки, в принятой на проекте среде реализации.
4. Если задача может быть решена разными способами (влияющими на стоимость решения), то специалист должен согласовать вариант реализации с заказчиком до начала работ.
5. Специалист предпочитает максимально использовать типовые возможности системы вместо программных доработок.
6. Вносить изменения в типовые конфигурации вендора (в случае необходимости) следует в максимально щадящем режиме. В качестве основы для изменений предпочтительно использовать широко-известные свободно-распространяемые готовые библиотеки.
7. Использование платных библиотек и иного встраиваемого кода, защищенного правами третьих лиц, должно быть согласованно с заказчиком.
8. Специалист назначает окончательную стоимость этапа работ или всего решения до начала работ над этапом (проектом).
9. Специалист укладывается в сроки, которые озвучивает, и самостоятельно уведомляет заказчика о готовности работы.
10. Специалист регулярно выходит на связь с заказчиком, демонстрирует ему промежуточные результаты работы и, по необходимости, корректирует направление разработки.
11. Специалист отвечает на вопросы заказчика своевременно и по существу. Если ответ на вопрос требует времени, то специалист уведомляет заказчика о временных рамках, необходимых ему для ответа.
12. Специалист выбирает сотрудничество и диалог вместо критики и поучений.
13. Специалист самостоятельно тестирует свои решения и вносит в них коррективы, в случае обнаружения багов.
14. Специалист документирует разработку и комментирует программный код.
15. Если в процессе работы над проектом специалист видит «неоптимальности» или явные ошибки в уже реализованном функционале, то он сообщает об этом заказчику и, при его согласии, устраняет их за доп. плату.
16. Специалист сохраняет работоспособность ранее внесенных в продукт изменений (если иное не следует из задачи). Проверяет исправность имеющихся механизмов в случае пересечения функционала.
17. После внедрения изменений в промышленную эксплуатацию, специалист готов к оперативному устранению выявленных недостатков, связанных с потерей работоспособности механизмов, вызванных изменениями.
18. Специалист не ограничивает доступ заказчика к ПО, программному коду, базам данных, файлам и сервисам, используемым для функционирования ПО или интегрируемым с ним, не шифрует данные, а также не устанавливает пароли и прочие ограничения.
19. За нарушение пунктов настоящего соглашения или их игнорирование специалист может получить предупреждение от заказчика. При повторных систематических нарушениях специалист отстраняется от проекта.
Как работать с соглашением?
Я использую его в нескольких форматах. Ни один из них я не считаю приоритетным. Все зависит от масштабов проекта, опыта и квалификации программиста, а также от степени обоюдного доверия между PM-ом и специалистом.
1. Можно сделать это соглашение приложением к договору.
2. Можно открыть его и совместно обсудить каждый пункт с последующей подписью.
3. Можно выложить в общий доступ для всех участников проекта, сделав документ рекомендуемым к изучению.
Предлагаю вам свод таких правил, накопленных за годы руководства проектами. Какие-то пункты вам могут показаться очевидными, какие-то вызовут интерес или отторжение, некоторые – удивление, но все они, так или иначе, отработаны на практике и проверены в боях. Так что можете смело адаптировать их под себя и пользоваться.
☑️ Соглашение о сотрудничестве:
Данное соглашение призвано установить доверительно-деловой климат при совместной работе над проектами и решением сопутствующих задач.
1. Если специалист понимает, что задача поставлена некорректно, то он ее уточняет до степени взаимно-однозначного соответствия с заказчиком.
2. Специалист предлагает возможные варианты решения, которые могут быть полезны для проекта, но упущены из поля видимости заказчиком.
3. Специалист соблюдает рекомендуемые методики проектирования, уделяет внимание чистоте и эргономике интерфейсов, придерживается стандартов разработки, в принятой на проекте среде реализации.
4. Если задача может быть решена разными способами (влияющими на стоимость решения), то специалист должен согласовать вариант реализации с заказчиком до начала работ.
5. Специалист предпочитает максимально использовать типовые возможности системы вместо программных доработок.
6. Вносить изменения в типовые конфигурации вендора (в случае необходимости) следует в максимально щадящем режиме. В качестве основы для изменений предпочтительно использовать широко-известные свободно-распространяемые готовые библиотеки.
7. Использование платных библиотек и иного встраиваемого кода, защищенного правами третьих лиц, должно быть согласованно с заказчиком.
8. Специалист назначает окончательную стоимость этапа работ или всего решения до начала работ над этапом (проектом).
9. Специалист укладывается в сроки, которые озвучивает, и самостоятельно уведомляет заказчика о готовности работы.
10. Специалист регулярно выходит на связь с заказчиком, демонстрирует ему промежуточные результаты работы и, по необходимости, корректирует направление разработки.
11. Специалист отвечает на вопросы заказчика своевременно и по существу. Если ответ на вопрос требует времени, то специалист уведомляет заказчика о временных рамках, необходимых ему для ответа.
12. Специалист выбирает сотрудничество и диалог вместо критики и поучений.
13. Специалист самостоятельно тестирует свои решения и вносит в них коррективы, в случае обнаружения багов.
14. Специалист документирует разработку и комментирует программный код.
15. Если в процессе работы над проектом специалист видит «неоптимальности» или явные ошибки в уже реализованном функционале, то он сообщает об этом заказчику и, при его согласии, устраняет их за доп. плату.
16. Специалист сохраняет работоспособность ранее внесенных в продукт изменений (если иное не следует из задачи). Проверяет исправность имеющихся механизмов в случае пересечения функционала.
17. После внедрения изменений в промышленную эксплуатацию, специалист готов к оперативному устранению выявленных недостатков, связанных с потерей работоспособности механизмов, вызванных изменениями.
18. Специалист не ограничивает доступ заказчика к ПО, программному коду, базам данных, файлам и сервисам, используемым для функционирования ПО или интегрируемым с ним, не шифрует данные, а также не устанавливает пароли и прочие ограничения.
19. За нарушение пунктов настоящего соглашения или их игнорирование специалист может получить предупреждение от заказчика. При повторных систематических нарушениях специалист отстраняется от проекта.
Как работать с соглашением?
Я использую его в нескольких форматах. Ни один из них я не считаю приоритетным. Все зависит от масштабов проекта, опыта и квалификации программиста, а также от степени обоюдного доверия между PM-ом и специалистом.
1. Можно сделать это соглашение приложением к договору.
2. Можно открыть его и совместно обсудить каждый пункт с последующей подписью.
3. Можно выложить в общий доступ для всех участников проекта, сделав документ рекомендуемым к изучению.
Можно использовать все три пункта в желаемых комбинациях по ситуации.
✅ Преимущества такого соглашения очевидны:
1. Специалист сразу понимает объем ответственности и, если внутренне он согласен с ним, то в дальнейшем какие-либо эксцессы легко разрешаются. Если же какие-то пункты требуют разъяснений, то это тоже легко решается в беседе.
Таким образом, все вопросы, при достижении консенсуса по соглашению, будут закрыты на берегу.
2. Неопытные специалисты могут испугаться каких-либо положений из списка. В качестве одного из эффектов соглашение может выполнять функцию своеобразного фильтра при найме.
⚠️ Важно!
Мои наблюдения показывают, что hard-skill программисты, не обладающие развитыми социально-ориентированными навыками, чаще других пропадают после ознакомления со столь «обременяющими» условиями.
Так что, если стиль вашей работы в качестве менеджера проекта позволяет иметь в команде таких людей, то будьте аккуратнее с этим соглашением – вы можете упустить молчаливых гениев.
Удачи вам в использовании соглашения и прорывных идей! 💯
✅ Преимущества такого соглашения очевидны:
1. Специалист сразу понимает объем ответственности и, если внутренне он согласен с ним, то в дальнейшем какие-либо эксцессы легко разрешаются. Если же какие-то пункты требуют разъяснений, то это тоже легко решается в беседе.
Таким образом, все вопросы, при достижении консенсуса по соглашению, будут закрыты на берегу.
2. Неопытные специалисты могут испугаться каких-либо положений из списка. В качестве одного из эффектов соглашение может выполнять функцию своеобразного фильтра при найме.
⚠️ Важно!
Мои наблюдения показывают, что hard-skill программисты, не обладающие развитыми социально-ориентированными навыками, чаще других пропадают после ознакомления со столь «обременяющими» условиями.
Так что, если стиль вашей работы в качестве менеджера проекта позволяет иметь в команде таких людей, то будьте аккуратнее с этим соглашением – вы можете упустить молчаливых гениев.
Удачи вам в использовании соглашения и прорывных идей! 💯
Соглашение о сотрудничестве.pdf
200.8 KB
Кстати, для тех, кто хочет скачать соглашение прилагаю сам файл - держите🧷
Знаете, что больше всего выдает в вас низкоквалифицированного программиста?
Желание неукоснительно придерживаться ТЗ при недостигнутых задачах бизнеса. 🆘
Этот тезис больно ударит по вашему самолюбию, если вы привыкли к уровню обслуживания «нет в ТЗ – идите мимо». Тем не менее, если вы хотя бы чуть-чуть поменяете свое мнение в сторону большей клиентоориентированности, то сможете понять, о чем я.
Знаю-знаю, вы – крутой программист и тут же возразите мне – а что же, я должен предвидеть все, что нужно бизнесу? Должен догадаться, чего хочет заказчик? Бесконечно реализовывать его странные хотелки?
⚠️ А имеете ли вы моральное право задавать такие вопросы?
Проверьте, что из этого списка вы сделали для этого:
▪️Провели ли вы предварительный анализ требований из ТЗ, прежде чем приступить к его реализации?
▪️Поставили ли вы под сомнение какие-либо пункты в спецификации или простовзяли под козырек получили аванс?
▪️Предложили ли вы заказчику альтернативные варианты решения?
Если ваш ответ «ничего», значит вы просто формалист, перекладывающий ответственность с себя на заказчика.
Вы до потертости пальцев будете тыкать в ТЗ, говорить, что оно утверждено и подписано заказчиком. Что он сам виноват в том, что не углядел/не дописал, а теперь топает ногами и требует, чтобы вы доделали работу, но никогда не признаетесь, в том, что не смогли здраво оценить свои силы, потому как некомпетентны.
❗️Знайте, если вы так делаете, то вы низкоквалифицированный программист-техник, не больше!
Нужны обоснования? – пожалуйста.
🔰 Что говорит профстандарт о вашей квалификации?
Вы наверняка знаете, что есть так называемые профессиональные стандарты. Они разработаны компетентными органами с целью определить эталонные навыки и умения специалистов, отвечающих за свою работу.
ℹ️ Здесь находится профстандарт для программистов. Это сайт министерства труда.
Если мы заглянем внутрь профстандарта, то обнаружим, что одна из трудовых функций программиста выглядит так:
✔️Написание программного кода с использованием языков программирования, определения и манипулирования данными
В рамках этой трудовой функции определены следующие трудовые действия:
▪️Создание программного кода в соответствии с техническим заданием (готовыми спецификациями)
▪️Оптимизация программного кода с использованием специализированных программных средств
▪️Оценка и согласование сроков выполнения поставленных задач
Действительно, исходя из этого стандарта, мы видим, что программист создает программный код, опираясь на техническое задание (готовую спецификацию). Для этого ему достаточно владеть синтаксисом выбранного языка программирования, уметь оптимизировать программный код и проводить оценку работ по срокам.
Интересно, что программист, который обладает навыками кодинга по ТЗ, получает от Минтруда только 3 пункта к квалификации. Это программист уровня ПТУ, совершенно обоснованно в терминах профстандарта именуемый «Младший программист» или «Техник-программист». 〽️
Такой специалист может заявить: «в ТЗ этого нет». Формально он будет прав – это его уровень. Ему все равно, реализована ли задача бизнеса, главное, что свою часть работы он сделал.
Аналогом такого подхода могут служить следующие примеры:
▪️Лампочку вкрутил, но свет есть только в 70% теплицы. Для появления завязей необходим уровень наполняемости светом 99%.
▪️Реализовал функцию оплаты заказов, при этом не учел, что оплачивать заказы могут только зарегистрированные пользователи.
▪️Сделал парсер для сайта, но подтягиваемые данные выводятся вкривь-вкось.
Смотрим далее. Есть такая трудовая функция как
✔️Анализ требований к программному обеспечению
А вот это уже посложнее будет, ведь для того, чтобы реализовать столь очевидно-полезную для бизнеса трудовую функцию, действительно нужен фундаментальный подход и мозги, а также пресловутые софт-скилс, которыми не обладают «техники» квалификации 3.
Желание неукоснительно придерживаться ТЗ при недостигнутых задачах бизнеса. 🆘
Этот тезис больно ударит по вашему самолюбию, если вы привыкли к уровню обслуживания «нет в ТЗ – идите мимо». Тем не менее, если вы хотя бы чуть-чуть поменяете свое мнение в сторону большей клиентоориентированности, то сможете понять, о чем я.
Знаю-знаю, вы – крутой программист и тут же возразите мне – а что же, я должен предвидеть все, что нужно бизнесу? Должен догадаться, чего хочет заказчик? Бесконечно реализовывать его странные хотелки?
⚠️ А имеете ли вы моральное право задавать такие вопросы?
Проверьте, что из этого списка вы сделали для этого:
▪️Провели ли вы предварительный анализ требований из ТЗ, прежде чем приступить к его реализации?
▪️Поставили ли вы под сомнение какие-либо пункты в спецификации или просто
▪️Предложили ли вы заказчику альтернативные варианты решения?
Если ваш ответ «ничего», значит вы просто формалист, перекладывающий ответственность с себя на заказчика.
Вы до потертости пальцев будете тыкать в ТЗ, говорить, что оно утверждено и подписано заказчиком. Что он сам виноват в том, что не углядел/не дописал, а теперь топает ногами и требует, чтобы вы доделали работу, но никогда не признаетесь, в том, что не смогли здраво оценить свои силы, потому как некомпетентны.
❗️Знайте, если вы так делаете, то вы низкоквалифицированный программист-техник, не больше!
Нужны обоснования? – пожалуйста.
🔰 Что говорит профстандарт о вашей квалификации?
Вы наверняка знаете, что есть так называемые профессиональные стандарты. Они разработаны компетентными органами с целью определить эталонные навыки и умения специалистов, отвечающих за свою работу.
ℹ️ Здесь находится профстандарт для программистов. Это сайт министерства труда.
Если мы заглянем внутрь профстандарта, то обнаружим, что одна из трудовых функций программиста выглядит так:
✔️Написание программного кода с использованием языков программирования, определения и манипулирования данными
В рамках этой трудовой функции определены следующие трудовые действия:
▪️Создание программного кода в соответствии с техническим заданием (готовыми спецификациями)
▪️Оптимизация программного кода с использованием специализированных программных средств
▪️Оценка и согласование сроков выполнения поставленных задач
Действительно, исходя из этого стандарта, мы видим, что программист создает программный код, опираясь на техническое задание (готовую спецификацию). Для этого ему достаточно владеть синтаксисом выбранного языка программирования, уметь оптимизировать программный код и проводить оценку работ по срокам.
Интересно, что программист, который обладает навыками кодинга по ТЗ, получает от Минтруда только 3 пункта к квалификации. Это программист уровня ПТУ, совершенно обоснованно в терминах профстандарта именуемый «Младший программист» или «Техник-программист». 〽️
Такой специалист может заявить: «в ТЗ этого нет». Формально он будет прав – это его уровень. Ему все равно, реализована ли задача бизнеса, главное, что свою часть работы он сделал.
Аналогом такого подхода могут служить следующие примеры:
▪️Лампочку вкрутил, но свет есть только в 70% теплицы. Для появления завязей необходим уровень наполняемости светом 99%.
▪️Реализовал функцию оплаты заказов, при этом не учел, что оплачивать заказы могут только зарегистрированные пользователи.
▪️Сделал парсер для сайта, но подтягиваемые данные выводятся вкривь-вкось.
Смотрим далее. Есть такая трудовая функция как
✔️Анализ требований к программному обеспечению
А вот это уже посложнее будет, ведь для того, чтобы реализовать столь очевидно-полезную для бизнеса трудовую функцию, действительно нужен фундаментальный подход и мозги, а также пресловутые софт-скилс, которыми не обладают «техники» квалификации 3.
👍1🤩1
Читаем состав трудовых действий:
• Анализ возможностей реализации требований к программному обеспечению
• Оценка времени и трудоемкости реализации требований к программному обеспечению
• Согласование требований к программному обеспечению с заинтересованными сторонами
• Оценка и согласование сроков выполнения поставленных задач
И необходимые умения:
• Проводить анализ исполнения требований
• Вырабатывать варианты реализации требований
• Проводить оценку и обоснование рекомендуемых решений
• Осуществлять коммуникации с заинтересованными сторонами
Здесь на первый план выходят социально-ориентированные навыки специалиста: умение общаться, задавать вопросы, вести дискуссию, в чем-то отстаивать свою позицию, где-то прислушаться к иной позиции. 👋
Нетрудно заметить, что из 4 трудовых действий и 4 необходимых умений присутствуют только 2 технических навыка!
А теперь немного о том, как называется эта должность и об уровне необходимой квалификации.
✅ Ведущий программист или ведущий инженер-программист
Минтрудом этот уровень квалификации оценивается в 6 баллов, что объективно выше, чем у техника-программиста с уровнем 3 🤷
Становится очевидным, что для того, чтобы быть в авангарде своей профессии и приносить бизнесу пользу, нужно быть не просто человеком-печатной машинкой кода, а аналитиком.
Вы имеете право говорить о «бесконечных доделках», если вы:
▪️Предварительно и в полной мере убедились, что требования, положенные в ТЗ, определяются бизнес-задачей и неразрывно связаны с ней.
▪️Задали заказчику исчерпывающие вопросы и утвердились в понимании «почему» и «зачем» необходимо реализовать ту или иную бизнес функцию, в результате которой родились функциональные требования, описанные в ТЗ.
📢 Другими словами программист, обладающий развитыми аналитическими навыками, в любой момент времени понимает, как именно конкретное функциональное требование соотносится с бизнес-задачей и наоборот – какой бизнес-задачей порождено соответствующее функциональное требование, на что оно опирается.
И называется такой программист ведущим!
✅ Для него подход «такого не было в ТЗ» - катастрофа, ведь он осознает, что ТЗ – это сфера его ответственности.
✅ Ведущий программист выполняет 60% работы на этапе аналитики и только 40% отводит на работу с кодом.
✅ Он не делает ТЗ притчей во языцех, доказывая несостоятельность заказчика. Скорее, наоборот, он чувствует себя несостоятельным, если, сделав работу по ТЗ, заказчик получает не тот результат, на который рассчитывал.
Это колоссальная разница в подходах и мышлении – заметьте!
Если программист не видит связи задач с бизнесом и не принимает каких-либо действий для обнаружения такой связи, то это программист-техник.
• Анализ возможностей реализации требований к программному обеспечению
• Оценка времени и трудоемкости реализации требований к программному обеспечению
• Согласование требований к программному обеспечению с заинтересованными сторонами
• Оценка и согласование сроков выполнения поставленных задач
И необходимые умения:
• Проводить анализ исполнения требований
• Вырабатывать варианты реализации требований
• Проводить оценку и обоснование рекомендуемых решений
• Осуществлять коммуникации с заинтересованными сторонами
Здесь на первый план выходят социально-ориентированные навыки специалиста: умение общаться, задавать вопросы, вести дискуссию, в чем-то отстаивать свою позицию, где-то прислушаться к иной позиции. 👋
Нетрудно заметить, что из 4 трудовых действий и 4 необходимых умений присутствуют только 2 технических навыка!
А теперь немного о том, как называется эта должность и об уровне необходимой квалификации.
✅ Ведущий программист или ведущий инженер-программист
Минтрудом этот уровень квалификации оценивается в 6 баллов, что объективно выше, чем у техника-программиста с уровнем 3 🤷
Становится очевидным, что для того, чтобы быть в авангарде своей профессии и приносить бизнесу пользу, нужно быть не просто человеком-печатной машинкой кода, а аналитиком.
Вы имеете право говорить о «бесконечных доделках», если вы:
▪️Предварительно и в полной мере убедились, что требования, положенные в ТЗ, определяются бизнес-задачей и неразрывно связаны с ней.
▪️Задали заказчику исчерпывающие вопросы и утвердились в понимании «почему» и «зачем» необходимо реализовать ту или иную бизнес функцию, в результате которой родились функциональные требования, описанные в ТЗ.
📢 Другими словами программист, обладающий развитыми аналитическими навыками, в любой момент времени понимает, как именно конкретное функциональное требование соотносится с бизнес-задачей и наоборот – какой бизнес-задачей порождено соответствующее функциональное требование, на что оно опирается.
И называется такой программист ведущим!
✅ Для него подход «такого не было в ТЗ» - катастрофа, ведь он осознает, что ТЗ – это сфера его ответственности.
✅ Ведущий программист выполняет 60% работы на этапе аналитики и только 40% отводит на работу с кодом.
✅ Он не делает ТЗ притчей во языцех, доказывая несостоятельность заказчика. Скорее, наоборот, он чувствует себя несостоятельным, если, сделав работу по ТЗ, заказчик получает не тот результат, на который рассчитывал.
Это колоссальная разница в подходах и мышлении – заметьте!
Если программист не видит связи задач с бизнесом и не принимает каких-либо действий для обнаружения такой связи, то это программист-техник.
🔰Как перестать быть программистом-техником и выйти на уровень компетенций ведущего программиста?
Чтобы соответствовать высоким показателям Минтруда и ожиданиям заказчиков нужно, в первую очередь, переориентировать фокус своего внимания с технической части на бизнес.
Хороший аналитик – это всегда про взаимопонимание людей. Нужно учиться общаться, задавать вопросы, интересоваться той сферой деятельности, потребности которой вы решаете. Аналитик должен знать и предметную область проекта, и применяемые техники разработки.
Вот примерный спектр умений для прокачки в себе аналитика и успешного бизнес-коммуникатора:
1. Анкетирование. Умение сделать качественную анкету под проект можно считать базовым навыком перед тем, как вступать в очные интервью.
2. Навык индивидуального интервьюирования. Сюда можно отнести персональные встречи, интервью по телефону и навыки выявления требований посредством переписки.
3. Групповые интервью. На групповых интервью присутствует несколько заинтересованных лиц. Ничего сложного. Просто здесь лучше проявляются ваши навыки самопрезентации, умение владеть вниманием собеседника, задавать вопросы и удерживать формат беседы, необходимый для получения результата.
4. Наблюдение. Иногда, для того, чтобы понять, как что-то работает, достаточно просто понаблюдать за этим. Уверяю, что посидев полтора часа в живом отделе продаж и просто наблюдая за менеджерами, вы точно поймете, как адаптировать эту злосчастную CRM так, чтобы руководство осталось довольным.
5. Прототипирование и создание бизнес-схем с последующим их обсуждением. Прототипы великолепны в качестве первого приближения результата. Если вы пришли на встречу с клиентом или общаетесь с ним в формате конференции онлайн – разверните флип-чарт и порисуйте. Ваша дискуссия обретет иной качественный характер и понимание.
Кроме того, рекомендую почитать следующую литературу:
✅ Карл Вигерс, Джой Битти – Разработка требований к программному обеспечению. Практические приемы сбора требований при разработке программных продуктов.
✅ Дин Леффингуэлл, Дон Уидриг – Принципы работы с требованиями к программному обеспечению. Унифицированный подход.
Этот перечень неограничен, но вполне достаточен на начальном этапе, чтобы открыть себе путь к более интересным проектам. Это ваш иной уровень зрелости как специалиста с доступом к другому уровню вознаграждения.
Удачи вам и крутых проектов! 👍
Чтобы соответствовать высоким показателям Минтруда и ожиданиям заказчиков нужно, в первую очередь, переориентировать фокус своего внимания с технической части на бизнес.
Хороший аналитик – это всегда про взаимопонимание людей. Нужно учиться общаться, задавать вопросы, интересоваться той сферой деятельности, потребности которой вы решаете. Аналитик должен знать и предметную область проекта, и применяемые техники разработки.
Вот примерный спектр умений для прокачки в себе аналитика и успешного бизнес-коммуникатора:
1. Анкетирование. Умение сделать качественную анкету под проект можно считать базовым навыком перед тем, как вступать в очные интервью.
2. Навык индивидуального интервьюирования. Сюда можно отнести персональные встречи, интервью по телефону и навыки выявления требований посредством переписки.
3. Групповые интервью. На групповых интервью присутствует несколько заинтересованных лиц. Ничего сложного. Просто здесь лучше проявляются ваши навыки самопрезентации, умение владеть вниманием собеседника, задавать вопросы и удерживать формат беседы, необходимый для получения результата.
4. Наблюдение. Иногда, для того, чтобы понять, как что-то работает, достаточно просто понаблюдать за этим. Уверяю, что посидев полтора часа в живом отделе продаж и просто наблюдая за менеджерами, вы точно поймете, как адаптировать эту злосчастную CRM так, чтобы руководство осталось довольным.
5. Прототипирование и создание бизнес-схем с последующим их обсуждением. Прототипы великолепны в качестве первого приближения результата. Если вы пришли на встречу с клиентом или общаетесь с ним в формате конференции онлайн – разверните флип-чарт и порисуйте. Ваша дискуссия обретет иной качественный характер и понимание.
Кроме того, рекомендую почитать следующую литературу:
✅ Карл Вигерс, Джой Битти – Разработка требований к программному обеспечению. Практические приемы сбора требований при разработке программных продуктов.
✅ Дин Леффингуэлл, Дон Уидриг – Принципы работы с требованиями к программному обеспечению. Унифицированный подход.
Этот перечень неограничен, но вполне достаточен на начальном этапе, чтобы открыть себе путь к более интересным проектам. Это ваш иной уровень зрелости как специалиста с доступом к другому уровню вознаграждения.
Удачи вам и крутых проектов! 👍
👏1
🖐 Привет!
В продолжение предыдущей темы хочу представить вашему вниманию популярные убеждения, порождающие конфликты с заказчиками из-за ТЗ 📃 Этот пост больше для ИТ-подрядчиков, но и заказчики, возможно, смогут взглянуть на рассматриваемую проблему с иного ракурса.
Контекст рассматриваемой проблемы: подрядчик (компания или лично программист) отказывается продолжать работы над проектом, мотивируя это недоработкой ТЗ. При этом проблема заказчика (бизнеса) остается нерешенной.
Нюанс заключается в том, что подрядчик (не все, но многие) по умолчанию считает недоработку ТЗ проблемой заказчика. Я объясню, почему это не так и что с этим можно сделать.
ℹ️ Почему так происходит?
В основе любого поведения, действия или бездействия лежат убеждения. Их можно заметить везде: в мимолетно брошенных фразах, разговорах или переписках. Иногда они находятся на поверхности, а иногда достаточно ловко скрываются от хозяина в лабиринтах его сознания. Копни чуть глубже – и вот оно – всплыло и никак не хочет тонуть. За ними не надо далеко ходить. Достаточно просто понаблюдать за сотрудниками в курилке или почитать комментарии на профильных порталах.
Если вытащить из них смысл, то получим примерно следующий набор убеждений с одним общим началом.
‼️ Нет смысла, мотивации и желания вникать в ТЗ, собирать и формализовывать требования, приводить их в соответствие с ожиданиями заказчика, потому что:
1. Заказчик не знает, чего хочет / не в состоянии выразить свои желания
2. Задачи бизнеса решает компания/менеджмент (не я лично)
3. Это не оплачивается (не учтено в KPI), значит, и делать не буду
4. Не хочу переделывать без внятного техзадания
5. Ответственность за ТЗ на заказчике (на бизнесе), т.к. он его подписал
6. Никто и никому ничего не должен
Следствие: бюрократия, прокрастинация, апатия, боль, разрыв отношений.
⚠️ Все эти убеждения задают климат работы над проектом и определяют ваши ограничения в нем. Причем не только единоличные, но и коллективные – чем больше таких убеждений приходится на участников проектной группы, тем вреднее это для ее коллективной динамики, пагубнее для результата и компании.
А теперь разберем каждое убеждение в отдельности и поймем, что с ним можно сделать с точки зрения психологии, собственного поведения и управленческого инструментария.
🔰 Заказчик не знает, чего хочет / не в состоянии выразить свои желания
Что сделать с точки зрения психологии?
▪️Допустить, что заказчик несовершенен. Что ему может быть трудно, в силу разных причин, сформировать образ конечного результата.
▪️Допустить, что он вовсе не обязан разбираться в технических тонкостях проекта.
▪️Принять тот факт, что его язык описания задачи может отличаться от вашего.
А еще представьте, что вы у врача. Вам было бы приятно быть выслушанными? Или будет достаточно безразлично-сурового «ну, что там у вас» и взгляд, такой, исподлобья? Возможно, вам трудно найти у себя в теле источник боли, вы мучаетесь, боль неоднородна и непонятна.
Вы бы хотели, чтобы доктор помог вам определиться с локализацией и причиной? Или, удостоившись дежурной пальпации и снисходительного простукивания, удовольствуетесь этим и ношпой, выписанной вслед? 🙈
И добивание: «приходите через две недели, если сильнее заболит». 🤕
Что сделать физически?
▪️Помочь клиенту осознать свою проблему.
▪️Задать компетентные вопросы, проясняющие детали желаемого результата.
▪️Собрать необходимую информацию.
▪️Предложить разные варианты решений. Обозначить границы таких решений.
▪️Выработать удобные для сторон правила взаимодействия, отвечающие на вопрос «как мы будем общаться?».
▪️Определить подходящую методологию для ведения проекта.
В продолжение предыдущей темы хочу представить вашему вниманию популярные убеждения, порождающие конфликты с заказчиками из-за ТЗ 📃 Этот пост больше для ИТ-подрядчиков, но и заказчики, возможно, смогут взглянуть на рассматриваемую проблему с иного ракурса.
Контекст рассматриваемой проблемы: подрядчик (компания или лично программист) отказывается продолжать работы над проектом, мотивируя это недоработкой ТЗ. При этом проблема заказчика (бизнеса) остается нерешенной.
Нюанс заключается в том, что подрядчик (не все, но многие) по умолчанию считает недоработку ТЗ проблемой заказчика. Я объясню, почему это не так и что с этим можно сделать.
ℹ️ Почему так происходит?
В основе любого поведения, действия или бездействия лежат убеждения. Их можно заметить везде: в мимолетно брошенных фразах, разговорах или переписках. Иногда они находятся на поверхности, а иногда достаточно ловко скрываются от хозяина в лабиринтах его сознания. Копни чуть глубже – и вот оно – всплыло и никак не хочет тонуть. За ними не надо далеко ходить. Достаточно просто понаблюдать за сотрудниками в курилке или почитать комментарии на профильных порталах.
Если вытащить из них смысл, то получим примерно следующий набор убеждений с одним общим началом.
‼️ Нет смысла, мотивации и желания вникать в ТЗ, собирать и формализовывать требования, приводить их в соответствие с ожиданиями заказчика, потому что:
1. Заказчик не знает, чего хочет / не в состоянии выразить свои желания
2. Задачи бизнеса решает компания/менеджмент (не я лично)
3. Это не оплачивается (не учтено в KPI), значит, и делать не буду
4. Не хочу переделывать без внятного техзадания
5. Ответственность за ТЗ на заказчике (на бизнесе), т.к. он его подписал
6. Никто и никому ничего не должен
Следствие: бюрократия, прокрастинация, апатия, боль, разрыв отношений.
⚠️ Все эти убеждения задают климат работы над проектом и определяют ваши ограничения в нем. Причем не только единоличные, но и коллективные – чем больше таких убеждений приходится на участников проектной группы, тем вреднее это для ее коллективной динамики, пагубнее для результата и компании.
А теперь разберем каждое убеждение в отдельности и поймем, что с ним можно сделать с точки зрения психологии, собственного поведения и управленческого инструментария.
🔰 Заказчик не знает, чего хочет / не в состоянии выразить свои желания
Что сделать с точки зрения психологии?
▪️Допустить, что заказчик несовершенен. Что ему может быть трудно, в силу разных причин, сформировать образ конечного результата.
▪️Допустить, что он вовсе не обязан разбираться в технических тонкостях проекта.
▪️Принять тот факт, что его язык описания задачи может отличаться от вашего.
А еще представьте, что вы у врача. Вам было бы приятно быть выслушанными? Или будет достаточно безразлично-сурового «ну, что там у вас» и взгляд, такой, исподлобья? Возможно, вам трудно найти у себя в теле источник боли, вы мучаетесь, боль неоднородна и непонятна.
Вы бы хотели, чтобы доктор помог вам определиться с локализацией и причиной? Или, удостоившись дежурной пальпации и снисходительного простукивания, удовольствуетесь этим и ношпой, выписанной вслед? 🙈
И добивание: «приходите через две недели, если сильнее заболит». 🤕
Что сделать физически?
▪️Помочь клиенту осознать свою проблему.
▪️Задать компетентные вопросы, проясняющие детали желаемого результата.
▪️Собрать необходимую информацию.
▪️Предложить разные варианты решений. Обозначить границы таких решений.
▪️Выработать удобные для сторон правила взаимодействия, отвечающие на вопрос «как мы будем общаться?».
▪️Определить подходящую методологию для ведения проекта.
👍2
Что сделать управленчески?
▪️Поставить взаимоотношения с клиентом выше ТЗ на уровне принципов компании.
▪️Определить правила взаимодействия с клиентами для всех вовлеченных ролей.
▪️Пресекать на уровне разговоров и переписок отношение «клиент – дурак».
▪️Продвигать среди персонала мысль, что именно клиент приносит компании прибыль. Не будет у компании прибыли – не будет зарплаты и премий у сотрудников.
▪️Ориентировать проектные команды на выстраивание долгосрочных отношений с клиентом.
▪️Задать KPI так, чтобы вознаграждение лиц, участвующих в постановке и сдаче работ клиенту, росло по мере поступления новых заказов от него.
Дополнительные пояснения
Ну, допустим, заказчик не знает, чего хочет. И что? 🤷
Помогите ему узнать это! Сделайте это частью вашей работы, если вы почему-то до сих пор считаете, что это не в ваших силах. Заказчик приходит к подрядчику с проблемой, с болью. И для начала хочет быть выслушанным. Развесьте уши – слушайте внимательно, не перебивайте, делайте вид, что вам интересно. А вам неинтересно? Тогда какого черта вы делаете на этой должности? Кто допустил вас до общения с заказчиком? 🤬
Может не стоит уже относиться к заказчикам как к дуракам? Предоставьте им сервис, внимание. Кем бы вы ни были. Какая в самом деле разница, какая у вас роль? Называетесь ли вы программист или аналитик, консультант или тим-лид.
Проявите простые человеческие качества, которые покажут заказчику, что вы заинтересованы сделать его бизнесу хорошо, а не вызвать у него ощущение безысходности от потраченных денег и неработающего работающего строго по ТЗ проекта.❤️
«Доцент тупой, но аппаратура при нем, при-нем!» А еще ваши деньги – они тоже при нем. Он их платит бизнесу: вам лично или той компании, которую вы представляете. Если вам выпало обслуживать этого непонимающего человека, составлять для него бестолкового ТЗ, то сделайте это, хотя бы один раз, по первому разряду!
Просто попробуйте. И вы увидите, что дураки вовсе не являются таковыми при вашем активном участии. Волшебным образом они превращаются сначала в непонимающего клиента, потом в активно сотрудничающего, затем они раскрываются, располагаются к вам доверием как к профессионалу высокого класса, несут вам свои деньги и дорожат полученным опытом!
👍 Кроме того, активно сотрудничающий клиент набирается сноровки. И даже, если однажды он был «туповат» по вашим меркам, то научив его работать, вы приобретаете в его лице не только постоянного заказчика, но и бесконечно признательного друга!
Что делать с остальными убеждениями расскажу далее. Следите за обновлениями🙂
А еще подписывайтесь на канал в яндекс.дзен: https://zen.yandex.ru/productmaster
▪️Поставить взаимоотношения с клиентом выше ТЗ на уровне принципов компании.
▪️Определить правила взаимодействия с клиентами для всех вовлеченных ролей.
▪️Пресекать на уровне разговоров и переписок отношение «клиент – дурак».
▪️Продвигать среди персонала мысль, что именно клиент приносит компании прибыль. Не будет у компании прибыли – не будет зарплаты и премий у сотрудников.
▪️Ориентировать проектные команды на выстраивание долгосрочных отношений с клиентом.
▪️Задать KPI так, чтобы вознаграждение лиц, участвующих в постановке и сдаче работ клиенту, росло по мере поступления новых заказов от него.
Дополнительные пояснения
Ну, допустим, заказчик не знает, чего хочет. И что? 🤷
Помогите ему узнать это! Сделайте это частью вашей работы, если вы почему-то до сих пор считаете, что это не в ваших силах. Заказчик приходит к подрядчику с проблемой, с болью. И для начала хочет быть выслушанным. Развесьте уши – слушайте внимательно, не перебивайте, делайте вид, что вам интересно. А вам неинтересно? Тогда какого черта вы делаете на этой должности? Кто допустил вас до общения с заказчиком? 🤬
Может не стоит уже относиться к заказчикам как к дуракам? Предоставьте им сервис, внимание. Кем бы вы ни были. Какая в самом деле разница, какая у вас роль? Называетесь ли вы программист или аналитик, консультант или тим-лид.
Проявите простые человеческие качества, которые покажут заказчику, что вы заинтересованы сделать его бизнесу хорошо, а не вызвать у него ощущение безысходности от потраченных денег и неработающего работающего строго по ТЗ проекта.❤️
«Доцент тупой, но аппаратура при нем, при-нем!» А еще ваши деньги – они тоже при нем. Он их платит бизнесу: вам лично или той компании, которую вы представляете. Если вам выпало обслуживать этого непонимающего человека, составлять для него бестолкового ТЗ, то сделайте это, хотя бы один раз, по первому разряду!
Просто попробуйте. И вы увидите, что дураки вовсе не являются таковыми при вашем активном участии. Волшебным образом они превращаются сначала в непонимающего клиента, потом в активно сотрудничающего, затем они раскрываются, располагаются к вам доверием как к профессионалу высокого класса, несут вам свои деньги и дорожат полученным опытом!
👍 Кроме того, активно сотрудничающий клиент набирается сноровки. И даже, если однажды он был «туповат» по вашим меркам, то научив его работать, вы приобретаете в его лице не только постоянного заказчика, но и бесконечно признательного друга!
Что делать с остальными убеждениями расскажу далее. Следите за обновлениями🙂
А еще подписывайтесь на канал в яндекс.дзен: https://zen.yandex.ru/productmaster
Дзен
ПРО-продукт
Канал для менеджеров проектов, владельцев бизнеса и управленцев, а также всех, кто относит себя к продуктологам и желает создавать качественные web-продукты.
🔥1
В прошлый раз мы выяснили, что причиной конфликтов между участниками проекта являются убеждения. Одно из таких убеждений мы уже рассмотрели. Теперь рассмотрим, что делать с другим популярным суждением.
🔰 Задачи бизнеса решает компания/менеджмент (не я лично)
Что сделать с точки зрения психологии?
Должно быть вы также уверены, что вас лечит больница, а не врач, обслуживает магазин, а не продавец, ну, вы поняли, да? Если вы работаете в коллективе, но не чувствуете личной ответственности за исход дела, то стоит найти в себе мужество сделать это. Признайтесь, что в случае, если проект будет закрыт хорошо, то вы будете чувствовать свою причастность к этому, даже если не общаетесь с клиентом лично, а, например, просто запрограммировали по классному ТЗ. Но если в ТЗ обнаружится косяк, то в этом случае вы скажете, что просто сделали, как было указано. Чувствуете фальшь?
Это как в футболе болеть за своих: выиграли – мы, а проиграли – они. Инфантильно, слабовольно, жидко.💩
Что сделать физически?
Если вы программист и кодите по ТЗ, спущенному сверху, увидели в нем ошибку, несоответствие или другую явную дичь, то вам стоит подойти к ответственному и сообщить об этом. Если ТЗ делали лично вы – все то же самое. Только идете к клиенту, уточняете задачу и вносите корректировки в проект.
Страшно? Больно? А кто сказал, что это легко? Выявить ошибку на ранних этапах работы обычно гораздо дешевле, чем сделать это в дальнейшем. Гораздо страшнее заложить из-за этого неправильную архитектуру в проект и узнать об этом на этапе приемо-сдаточных испытаний. По моим наблюдениям все упирается в банальные страхи типа «клиент не заплатит», «уволят за ошибку» или «я буду выглядеть дураком».
Признаюсь, что за свой 17-летний опыт проектной работы ни разу не видел таких последствий. Обычно, смелость в принятии сложных решений ценится окружающими и, если вы сумели вырулить ситуацию, то это только добавит вам профессиональных очков. 👑
А вот, если скрыли свою ошибку и об этом стало известно менеджменту и/или заказчику – вот тут уж палок не оберешься! О том, как нивелировать последствия таких ошибок, пожалуй, стоит написать отдельный пост.
Что сделать управленчески?
▪️Выявлять инициативных и ответственных сотрудников с тем, чтобы дать им больше личной ответственности в рамках проекта.
▪️Поощрять инициативы.
▪️Ввести коллективную ответственность через KPI.
В качестве примера: если задача из тестирования возвращалась на доработку более N раз, то использовать понижающий коэффициент от бонусной части за проект для программиста.
▪️Одновременно с этим заложить в процессы компании прозрачные механизмы эскалации проблем в случае обнаружения дефектов в ТЗ.
Хорошей практикой будет «задай 7 вопросов». В рамках этой практики ТЗ не просто спускается программисту, но и обязывает его задать не менее 7 вопросов по данному ТЗ постановщику. Больше можно, меньше нельзя. Отслеживать работу этого механизма.
▪️Ввести практику, при которой одновременно с ТЗ пишутся кейсы для тестировщиков. После чего ТЗ вместе с кейсами передается программистам.
▪️Проводить с персоналом коммуникативные тренинги, поощрять обмен информацией и сплоченность проектной команды.
Дополнительные пояснения
Подход «моя хата с краю» действительно встречается. В тех компаниях, где много бюрократии и формальностей между отделами эта проблема стоит особенно остро.
✅Общая рекомендация такая: объединять отделы, формировать проектные команды, выстраивать управление ИТ-проектами не по вертикали, а по смешанному типу. Это когда специалисты из разных отделов физически работают вместе. Их объединяет одно пространство – они могут общаться друг с другом в любой момент, когда того требует ситуация.
✅Нещадно сносить всю бюрократию: согласования, подписания, служебные записки и т.д. Проблемы решаются здесь и сейчас – ключевые лица всегда доступны. Процессы решения проблем прописаны и известны участникам проекта.
Что делать с остальными убеждениями расскажу далее. Следите за обновлениями🙂
А еще подписывайтесь на канал в яндекс.дзен: https://zen.yandex.ru/productmaster
🔰 Задачи бизнеса решает компания/менеджмент (не я лично)
Что сделать с точки зрения психологии?
Должно быть вы также уверены, что вас лечит больница, а не врач, обслуживает магазин, а не продавец, ну, вы поняли, да? Если вы работаете в коллективе, но не чувствуете личной ответственности за исход дела, то стоит найти в себе мужество сделать это. Признайтесь, что в случае, если проект будет закрыт хорошо, то вы будете чувствовать свою причастность к этому, даже если не общаетесь с клиентом лично, а, например, просто запрограммировали по классному ТЗ. Но если в ТЗ обнаружится косяк, то в этом случае вы скажете, что просто сделали, как было указано. Чувствуете фальшь?
Это как в футболе болеть за своих: выиграли – мы, а проиграли – они. Инфантильно, слабовольно, жидко.💩
Что сделать физически?
Если вы программист и кодите по ТЗ, спущенному сверху, увидели в нем ошибку, несоответствие или другую явную дичь, то вам стоит подойти к ответственному и сообщить об этом. Если ТЗ делали лично вы – все то же самое. Только идете к клиенту, уточняете задачу и вносите корректировки в проект.
Страшно? Больно? А кто сказал, что это легко? Выявить ошибку на ранних этапах работы обычно гораздо дешевле, чем сделать это в дальнейшем. Гораздо страшнее заложить из-за этого неправильную архитектуру в проект и узнать об этом на этапе приемо-сдаточных испытаний. По моим наблюдениям все упирается в банальные страхи типа «клиент не заплатит», «уволят за ошибку» или «я буду выглядеть дураком».
Признаюсь, что за свой 17-летний опыт проектной работы ни разу не видел таких последствий. Обычно, смелость в принятии сложных решений ценится окружающими и, если вы сумели вырулить ситуацию, то это только добавит вам профессиональных очков. 👑
А вот, если скрыли свою ошибку и об этом стало известно менеджменту и/или заказчику – вот тут уж палок не оберешься! О том, как нивелировать последствия таких ошибок, пожалуй, стоит написать отдельный пост.
Что сделать управленчески?
▪️Выявлять инициативных и ответственных сотрудников с тем, чтобы дать им больше личной ответственности в рамках проекта.
▪️Поощрять инициативы.
▪️Ввести коллективную ответственность через KPI.
В качестве примера: если задача из тестирования возвращалась на доработку более N раз, то использовать понижающий коэффициент от бонусной части за проект для программиста.
▪️Одновременно с этим заложить в процессы компании прозрачные механизмы эскалации проблем в случае обнаружения дефектов в ТЗ.
Хорошей практикой будет «задай 7 вопросов». В рамках этой практики ТЗ не просто спускается программисту, но и обязывает его задать не менее 7 вопросов по данному ТЗ постановщику. Больше можно, меньше нельзя. Отслеживать работу этого механизма.
▪️Ввести практику, при которой одновременно с ТЗ пишутся кейсы для тестировщиков. После чего ТЗ вместе с кейсами передается программистам.
▪️Проводить с персоналом коммуникативные тренинги, поощрять обмен информацией и сплоченность проектной команды.
Дополнительные пояснения
Подход «моя хата с краю» действительно встречается. В тех компаниях, где много бюрократии и формальностей между отделами эта проблема стоит особенно остро.
✅Общая рекомендация такая: объединять отделы, формировать проектные команды, выстраивать управление ИТ-проектами не по вертикали, а по смешанному типу. Это когда специалисты из разных отделов физически работают вместе. Их объединяет одно пространство – они могут общаться друг с другом в любой момент, когда того требует ситуация.
✅Нещадно сносить всю бюрократию: согласования, подписания, служебные записки и т.д. Проблемы решаются здесь и сейчас – ключевые лица всегда доступны. Процессы решения проблем прописаны и известны участникам проекта.
Что делать с остальными убеждениями расскажу далее. Следите за обновлениями🙂
А еще подписывайтесь на канал в яндекс.дзен: https://zen.yandex.ru/productmaster
Telegram
ПРО-продукт
🖐 Привет!
В продолжение предыдущей темы хочу представить вашему вниманию популярные убеждения, порождающие конфликты с заказчиками из-за ТЗ 📃 Этот пост больше для ИТ-подрядчиков, но и заказчики, возможно, смогут взглянуть на рассматриваемую проблему с иного…
В продолжение предыдущей темы хочу представить вашему вниманию популярные убеждения, порождающие конфликты с заказчиками из-за ТЗ 📃 Этот пост больше для ИТ-подрядчиков, но и заказчики, возможно, смогут взглянуть на рассматриваемую проблему с иного…
👍1
Что вы, как руководитель, можете сделать, когда программист постоянно переносит сроки?
▶️ Уволить программиста.
▶️ Узнать, в чем причина переносов и постараться помочь.
▶️ Забить и пусть оно само как-то катится - авось сделается.
Первый вариант сразу отбросим. Искать нового программиста дорого по времени и деньгам.🚫
Третий вариант для джедаев и массонов с неустановленным сроком пребывания в этой жизни - тоже не подходит🚫
Мы смертны, потому будем крутиться в рамках второго варианта.
А тут что? Ну, вот реально, что?!
Если отбросить всякую управленческую дребедень и рассуждать бытовым языком.
1. Шантаж?💊 Не сделаешь - не заплатим (демотивация, повод все бросить).
2. Пряник? Например, "сделаешь - получишь премию?"💵 - А за что премию, если в срок не уложился?
3. Увещевания, нытье, просьбы ускориться и войти в положение📢, т.к. партнёры нервничают, инвестиции срываются, доверие к проекту падает и т.п.?
Какой толк, если реально проект сложен и недооценен по времени? Если постоянно капать на мозг, возникнут депрессия и апатия, если не капать - сформируются неверные установки (я не успеваю, а всем пофиг - не буду и торопиться).
Что вы делаете в таких ситуациях? Есть ли реально работающие рычаги воздействия?⚙️
У кого какой опыт? - делитесь)
▶️ Уволить программиста.
▶️ Узнать, в чем причина переносов и постараться помочь.
▶️ Забить и пусть оно само как-то катится - авось сделается.
Первый вариант сразу отбросим. Искать нового программиста дорого по времени и деньгам.🚫
Третий вариант для джедаев и массонов с неустановленным сроком пребывания в этой жизни - тоже не подходит🚫
Мы смертны, потому будем крутиться в рамках второго варианта.
А тут что? Ну, вот реально, что?!
Если отбросить всякую управленческую дребедень и рассуждать бытовым языком.
1. Шантаж?💊 Не сделаешь - не заплатим (демотивация, повод все бросить).
2. Пряник? Например, "сделаешь - получишь премию?"💵 - А за что премию, если в срок не уложился?
3. Увещевания, нытье, просьбы ускориться и войти в положение📢, т.к. партнёры нервничают, инвестиции срываются, доверие к проекту падает и т.п.?
Какой толк, если реально проект сложен и недооценен по времени? Если постоянно капать на мозг, возникнут депрессия и апатия, если не капать - сформируются неверные установки (я не успеваю, а всем пофиг - не буду и торопиться).
Что вы делаете в таких ситуациях? Есть ли реально работающие рычаги воздействия?⚙️
У кого какой опыт? - делитесь)
🔥3
#Автоматизация #1С
🔰 Всем известно, что большинство компаний в РФ используют в качестве учетной системы 1С:Предприятие.
Когда рядовой собственник, сталкиваясь с огромной функциональной линейкой продуктов 1С, выбирает себе какую-то конкретную конфигурацию - не исключено, что он может ошибиться.
Например, выбрав 1С:Бухгалтерию, можно с удивлением узнать, что отражать некоторые торговые или производственные операции рядовому пользователю в ней неудобно. Неудобно получать управленческие отчеты в простом для понимания и наглядном виде.
⁉️Что делать? Переходить на другую конфигурацию? Да, именно так и делают в большинстве случаев. Но при этом сталкиваются с проблемой перехода.
Это когда программисты заламывают кучу денег на перевод документов из одной системы в другую, что переход на нее становится во много раз дороже, чем просто учет с нуля. При этом типового обмена данными между многими системами нет и предусмотрено не будет.
Столкнувшись несколько раз с такой необходимостью я стал искать решение и нашел его.
Делюсь с вами обработками по переводу документов, регистров и другой справочной информации из одной системы в другую.
Пользуйтесь на здоровье!
Перенос документов, остатков и справочников КА 1.1 => КА 2 / УТ 11;
Перенос документов, остатков и справочников КА 1.1 / УПП 1.3 => БП 3.0;Перенос документов, остатков и справочников КА 1.1 => ERP 2;
Перенос документов, остатков и справочников КА 1.1 => ЗУП 3;
Перенос документов, остатков и справочников УПП 1.3 => УТ 11 / КА 2 / ERP 2;
Перенос документов, остатков и справочников БП 3.0 => УНФ 1.6;
Перенос документов, остатков и справочников БП 3.0 => УТ 11 / КА 2 / ERP 2;
Перенос документов, остатков и справочников БП 3.0 => УТ 10.3;
Перенос документов, остатков и справочников БП 2.0 => УТ 11 / КА 2 / ERP 2;
Перенос документов, остатков и справочников БП 2.0 => БП 3.0;
Перенос документов и справочников БП 2.0 => КА 1.1;
Перенос документов, остатков и справочников УТ 10.3 => УТ 11 / КА 2 / ERP 2;
Перенос остатков кадровых и расчетных данных и справочников ЗУП 2.5 => КА 2 / ERP 2;
Перенос документов и справочников ERP 2 / КА 2 / УТ 11 => УПП 1.3 / КА 1.1 / УТ 10.3;
Перенос документов и справочников ERP 2 / КА 2 / УТ 11 => БП 3.0;
Перенос документов, остатков и справочников из ERP 2 / КА 2 / УТ 11 в УНФ 1.6;
Перенос документов, остатков и справочников из УНФ 1.6 в УТ 11 / КА 2 / ERP 2 (ЕРП 2);
Перенос данных из КА 1.1 / УПП 1.3 / УТ 10.3 в УНФ 1.6;
Перенос документов, остатков и справочников из КА 1.1 / УПП 1.3 / УТ 10.3 в Розница 2.3;
Перенос документов, остатков и справочников УНФ 1.6 => БП 3.0;
Перенос документов и справочной информации из БП 3.0 в УПП 1.3;
Перенос данных из 1С:Бухгалтерия 7.7 в БП 3.0;
Перенос документов, остатков и справочников УПП 1.3 Украина => BAS ERP;
Обработки отлажены, многократно проверены и имеют хорошую техподдержку.👍 Вам не придется переплачивать и вы сможете быстро запустить вашего заказчика на другой системе учета.
Ну, а если вы сам - владелец/менеджер компании - теперь вам проще принять решние🙂
🔰 Всем известно, что большинство компаний в РФ используют в качестве учетной системы 1С:Предприятие.
Когда рядовой собственник, сталкиваясь с огромной функциональной линейкой продуктов 1С, выбирает себе какую-то конкретную конфигурацию - не исключено, что он может ошибиться.
Например, выбрав 1С:Бухгалтерию, можно с удивлением узнать, что отражать некоторые торговые или производственные операции рядовому пользователю в ней неудобно. Неудобно получать управленческие отчеты в простом для понимания и наглядном виде.
⁉️Что делать? Переходить на другую конфигурацию? Да, именно так и делают в большинстве случаев. Но при этом сталкиваются с проблемой перехода.
Это когда программисты заламывают кучу денег на перевод документов из одной системы в другую, что переход на нее становится во много раз дороже, чем просто учет с нуля. При этом типового обмена данными между многими системами нет и предусмотрено не будет.
Столкнувшись несколько раз с такой необходимостью я стал искать решение и нашел его.
Делюсь с вами обработками по переводу документов, регистров и другой справочной информации из одной системы в другую.
Пользуйтесь на здоровье!
Перенос документов, остатков и справочников КА 1.1 => КА 2 / УТ 11;
Перенос документов, остатков и справочников КА 1.1 / УПП 1.3 => БП 3.0;Перенос документов, остатков и справочников КА 1.1 => ERP 2;
Перенос документов, остатков и справочников КА 1.1 => ЗУП 3;
Перенос документов, остатков и справочников УПП 1.3 => УТ 11 / КА 2 / ERP 2;
Перенос документов, остатков и справочников БП 3.0 => УНФ 1.6;
Перенос документов, остатков и справочников БП 3.0 => УТ 11 / КА 2 / ERP 2;
Перенос документов, остатков и справочников БП 3.0 => УТ 10.3;
Перенос документов, остатков и справочников БП 2.0 => УТ 11 / КА 2 / ERP 2;
Перенос документов, остатков и справочников БП 2.0 => БП 3.0;
Перенос документов и справочников БП 2.0 => КА 1.1;
Перенос документов, остатков и справочников УТ 10.3 => УТ 11 / КА 2 / ERP 2;
Перенос остатков кадровых и расчетных данных и справочников ЗУП 2.5 => КА 2 / ERP 2;
Перенос документов и справочников ERP 2 / КА 2 / УТ 11 => УПП 1.3 / КА 1.1 / УТ 10.3;
Перенос документов и справочников ERP 2 / КА 2 / УТ 11 => БП 3.0;
Перенос документов, остатков и справочников из ERP 2 / КА 2 / УТ 11 в УНФ 1.6;
Перенос документов, остатков и справочников из УНФ 1.6 в УТ 11 / КА 2 / ERP 2 (ЕРП 2);
Перенос данных из КА 1.1 / УПП 1.3 / УТ 10.3 в УНФ 1.6;
Перенос документов, остатков и справочников из КА 1.1 / УПП 1.3 / УТ 10.3 в Розница 2.3;
Перенос документов, остатков и справочников УНФ 1.6 => БП 3.0;
Перенос документов и справочной информации из БП 3.0 в УПП 1.3;
Перенос данных из 1С:Бухгалтерия 7.7 в БП 3.0;
Перенос документов, остатков и справочников УПП 1.3 Украина => BAS ERP;
Обработки отлажены, многократно проверены и имеют хорошую техподдержку.👍 Вам не придется переплачивать и вы сможете быстро запустить вашего заказчика на другой системе учета.
Ну, а если вы сам - владелец/менеджер компании - теперь вам проще принять решние🙂
solutions.drip-center.ru
Перенос данных из КА 1.1 в КА 2.5 (переносятся все документы из 1С:Комплексная автоматизация 1.1 в 2.5 / УТ 11)
Перенос данных из "1С:Комплексная автоматизация 1.1" в "1С:Комплексная автоматизация 2.х" / УТ 11. Переносятся все виды документов, а также НСИ и начальные остатки. Доступно несколько алгоритмов переноса начальных остатков на выбор (товары можно выгружать…
👍2🔥1
Сегодня собрал для вас ТОП-3 первородного зла, которое приведет вашего руководителя в ярость.😠💣
Повторяем только тогда, когда хотим быть уволенными или отстранённым от своих обязанностей 😁
1. Вы нарушаете договоренности и делаете это регулярно. Срываете сроки, пренебрегаете стандартами, избыточно или слишком вольно тратите имеющиеся ресурсы, действием или бездействием явно или неявно саботируете решения, под которыми подписались (в т.ч. условно).
2. Вы сделали задачу хуже, чем ожидал руководитель. При этом не утруждались в уточнениях и сверках промежуточного результата. Руководителю при этом приходится расхлёбывать последствия такого решения.
3. Вы не хотите изучать что-то новое для себя. Развиваться профессионально это не про вас. А ещё вы формально подходите к задачам, не стараясь достигнуть цели, которая стоит за их решением.
✅ В целом, надеюсь, это не про вас. Но иметь ввиду будет не лишним!
Наш канал в ДЗЕН: https://zen.yandex.ru/productmaster
Повторяем только тогда, когда хотим быть уволенными или отстранённым от своих обязанностей 😁
1. Вы нарушаете договоренности и делаете это регулярно. Срываете сроки, пренебрегаете стандартами, избыточно или слишком вольно тратите имеющиеся ресурсы, действием или бездействием явно или неявно саботируете решения, под которыми подписались (в т.ч. условно).
2. Вы сделали задачу хуже, чем ожидал руководитель. При этом не утруждались в уточнениях и сверках промежуточного результата. Руководителю при этом приходится расхлёбывать последствия такого решения.
3. Вы не хотите изучать что-то новое для себя. Развиваться профессионально это не про вас. А ещё вы формально подходите к задачам, не стараясь достигнуть цели, которая стоит за их решением.
✅ В целом, надеюсь, это не про вас. Но иметь ввиду будет не лишним!
Наш канал в ДЗЕН: https://zen.yandex.ru/productmaster
Дзен
ПРО-продукт
Канал для менеджеров проектов, владельцев бизнеса и управленцев, а также всех, кто относит себя к продуктологам и желает создавать качественные web-продукты.
🙏2
Случалось ли в вашей управленческой практике, когда на обратную связь сотрудникам об их некачественной работе, вы сталкивались с неадекватной ответной реакцией в стиле: "Я работаю так и только так. Не нравится - увольте меня!" - было такое?⚠️
Если да, поздравляю - этого сотрудника вы потеряли гораздо раньше, чем сложилась данная ситуация. 💡
Скорее всего, в какой-то момент вы не заметили "противоправных" действий сотрудника и спустили все на тормозах. Возник эффект "привыкания" или "права обычая", по которому сотрудник, не получивший вовремя порцию конструктивной критики, считает вполне нормальным работать спустя рукава.😤
Что делать?
✅ Проводить встречи с персоналом, допускающим отклонения от установленных регламентов, норм и правил.
ВАЖНО: делать это надо регулярно и сразу, как только вами выявлен случай пренебрежительного отношения к своим обязанностям❗️Сразу, но не вмешиваясь в действия сотрудника здесь и сейчас, а, например, по завершению рабочего дня, чтобы в спокойной обстановке прояснить ситуацию.
Не менее важно то, что такие обязанности должны быть описаны.📝
И здесь я говорю не о бюрократии, а о фиксации договоренностей между вами и персоналом. Это могут быть лаконичные и наглядные документы, где зафиксировано, что сотрудник должен делать и как (это не менее важно!) или даже чек-листы.
Договоренности, зафиксированные устно, к сожалению не работают.
Наш канал в ДЗЕН: https://zen.yandex.ru/productmaster
Если да, поздравляю - этого сотрудника вы потеряли гораздо раньше, чем сложилась данная ситуация. 💡
Скорее всего, в какой-то момент вы не заметили "противоправных" действий сотрудника и спустили все на тормозах. Возник эффект "привыкания" или "права обычая", по которому сотрудник, не получивший вовремя порцию конструктивной критики, считает вполне нормальным работать спустя рукава.😤
Что делать?
✅ Проводить встречи с персоналом, допускающим отклонения от установленных регламентов, норм и правил.
ВАЖНО: делать это надо регулярно и сразу, как только вами выявлен случай пренебрежительного отношения к своим обязанностям❗️Сразу, но не вмешиваясь в действия сотрудника здесь и сейчас, а, например, по завершению рабочего дня, чтобы в спокойной обстановке прояснить ситуацию.
Не менее важно то, что такие обязанности должны быть описаны.📝
И здесь я говорю не о бюрократии, а о фиксации договоренностей между вами и персоналом. Это могут быть лаконичные и наглядные документы, где зафиксировано, что сотрудник должен делать и как (это не менее важно!) или даже чек-листы.
Договоренности, зафиксированные устно, к сожалению не работают.
Наш канал в ДЗЕН: https://zen.yandex.ru/productmaster
Дзен
ПРО-продукт
Канал для менеджеров проектов, владельцев бизнеса и управленцев, а также всех, кто относит себя к продуктологам и желает создавать качественные web-продукты.
👍1
В продолжение предыдущего поста...
На встрече лучшим из возможных действий будет выявить истинную природу неприемлемого поведения сотрудника.👹
Это бывает сложно, т.к. не всякий человек позволит быстро до нее докопаться. Хорошая новость состоит в том, что вы сразу почувствуете, когда дойдете до сути. - Как? - С помощью предельно честного и открытого диалога.🗣❤️
Реальная причина обычно находится за гранью привычных начальству представлений о морали и нравственности.👻
Это что-то типа ассиметричных санкций, о которых говорят политики - вы ждёте подвоха в одном месте, а он приходит совершенно с другой стороны 😁 Более того, сотрудники могут наложить на вас "санкции" по абсолютно надуманным поводам.
Ну, точнее, для самого сотрудника этот повод будет очень даже веским! Проблема в том, что вы о нем не узнаете, пока не копнете. Глубоко, набравшись терпения и включив в дело ваш эмоциональный интеллект.🫴
У меня был программист, который тянул время проекта только потому, что я, оказывается, дал ему "сверхзадание". При этом для меня оно выглядело предельно лёгким, было не принципиальным к выполнению, и более того, на мою просьбу, - а это была именно просьба - он сказал мне: "Да, сделаю". И это после того, как мы все подробно обсудили.
Я был уверен, что у нас здесь полное взаимопонимание и порядок, ведь до этого момента мы уже долго сотрудничали. С его стороны я получал качественную работу, а он от меня - регулярную оплату без задержек.
Затем он стал пропадать, неохотно выходил на связь, говорил, что устал. Далее хуже - на мои вопросы отвечал сухо, односложно. Когда время затянулось чрезмерно, я настойчиво попросил его, таки, закончить с задачей.
На что он сказал, что больше не будет работать над моими проектами и разрывает контракт 🤕😱
Я немного опешил, но сумел сдержать себя. Оказалось, что этот программист был недоволен тем, что я "постоянно даю ему дополнительные задания без оплаты" 😲
Уточнив, что значит "постоянно", я выяснил, что у него в голове уже давно тикал счётчик моей неофициальной задолженности перед ним, по задачам, которые давно были закрыты. Естественно, я был не в курсе такого положения дел, т.к. он ни разу об этом не обмолвился. Явно попросить оплатить задолженность по своему внутреннему "счетчику" он почему-то не мог, а я считал, что плачу ему достаточно для того, чтобы выполнить мою просьбу в этот раз.
Еще большее непонимание у меня вызывало то, что вознаграждение за свою работу он всегда называл самостоятельно, а я с ним и не торговался и платил, сколько он скажет.
В общем, поговорили мы тогда по душам. Главное, что разобрались и продолжили сотрудничество🤝
Вот так бывает!
На встрече лучшим из возможных действий будет выявить истинную природу неприемлемого поведения сотрудника.👹
Это бывает сложно, т.к. не всякий человек позволит быстро до нее докопаться. Хорошая новость состоит в том, что вы сразу почувствуете, когда дойдете до сути. - Как? - С помощью предельно честного и открытого диалога.🗣❤️
Реальная причина обычно находится за гранью привычных начальству представлений о морали и нравственности.👻
Это что-то типа ассиметричных санкций, о которых говорят политики - вы ждёте подвоха в одном месте, а он приходит совершенно с другой стороны 😁 Более того, сотрудники могут наложить на вас "санкции" по абсолютно надуманным поводам.
Ну, точнее, для самого сотрудника этот повод будет очень даже веским! Проблема в том, что вы о нем не узнаете, пока не копнете. Глубоко, набравшись терпения и включив в дело ваш эмоциональный интеллект.🫴
У меня был программист, который тянул время проекта только потому, что я, оказывается, дал ему "сверхзадание". При этом для меня оно выглядело предельно лёгким, было не принципиальным к выполнению, и более того, на мою просьбу, - а это была именно просьба - он сказал мне: "Да, сделаю". И это после того, как мы все подробно обсудили.
Я был уверен, что у нас здесь полное взаимопонимание и порядок, ведь до этого момента мы уже долго сотрудничали. С его стороны я получал качественную работу, а он от меня - регулярную оплату без задержек.
Затем он стал пропадать, неохотно выходил на связь, говорил, что устал. Далее хуже - на мои вопросы отвечал сухо, односложно. Когда время затянулось чрезмерно, я настойчиво попросил его, таки, закончить с задачей.
На что он сказал, что больше не будет работать над моими проектами и разрывает контракт 🤕😱
Я немного опешил, но сумел сдержать себя. Оказалось, что этот программист был недоволен тем, что я "постоянно даю ему дополнительные задания без оплаты" 😲
Уточнив, что значит "постоянно", я выяснил, что у него в голове уже давно тикал счётчик моей неофициальной задолженности перед ним, по задачам, которые давно были закрыты. Естественно, я был не в курсе такого положения дел, т.к. он ни разу об этом не обмолвился. Явно попросить оплатить задолженность по своему внутреннему "счетчику" он почему-то не мог, а я считал, что плачу ему достаточно для того, чтобы выполнить мою просьбу в этот раз.
Еще большее непонимание у меня вызывало то, что вознаграждение за свою работу он всегда называл самостоятельно, а я с ним и не торговался и платил, сколько он скажет.
В общем, поговорили мы тогда по душам. Главное, что разобрались и продолжили сотрудничество🤝
Вот так бывает!
👏2
🔰Если ты владелец IT-продукта и болеешь за свое дело, то без качественных технических заданий не обойтись.
В больших нетиповых проектах постановка и формирование ТЗ становится нетривиальной. Нужно описать много условий, ветвлений и прочих сложных логических конструкций, которые «с наскоку» не реализовать, ведь на бумаге это выглядит лишь как набор абстракций.
А так уж устроен наш мозг, что ему нужна конкретика и образы!💁👁
Взять, например, разработку фриланс-портала. У проекта обычно несколько статусов. Всякий статус доступен для пользователей с разными ролями, у каждой роли есть набор атрибутов и свойств, характерных только для этого статуса и этой роли. А еще есть дополнительные, вроде бы, автономные сущности такие как «Переписка», «Оплата», «Отзывы». Они вроде бы самостоятельные, но, так или иначе, перекликаются со статусами и ролями.
❗️ Все это при пересечении дает очень большой набор вариантов, который нужно запрограммировать.
Возникает вопрос, как подать информацию специалисту, чтобы она была действительно понятна и непротиворечива, и, желательно, наглядна?
Есть всего два возможных базовых варианта.
✅ Вариант 1. Подумать и сформулировать набор правил для каждой сущности.
Например, берем сущность «Переписка» и формулируем правила по ее доступности. Это может выглядеть следующим образом:
Если между специалистом и заказчиком была переписка, то она блокируется при следующих условиях:
a. Проект получает статус «Заблокирован»
b. Проект получает признак «Снят с публикации»
c. Проект получает статус «Закрыт» (полное закрытие)
d. Специалист отказался от выполнения проекта на этапе поиска исполнителя
На данном этапе важно, чтобы правилом покрывались все возможные варианты событий.
Если этого не произойдет, а программист не подумает самостоятельно (или не задаст вам вопросы), то вы можете получить достаточно неприятные сюрпризы на этапе приемки проекта.
⚠️ Кстати, как вы думаете, какой сюрприз (явно ненужный нам) можно получить по этому правилу? Напишите в комментариях, если заметите! 🤷
Когда вы формулируете такие правила важно донести до специалистов необходимость в их критичном восприятии! Если на этапе реализации они смогут увидеть несовершенства в формулировках, то должны дать вам немедленную обратную связь, чтобы уточнить правило.
Лайфхак: это лучше зафиксировать в проектной документации в качестве принципа работы!
Таким образом, ваше ТЗ будет состоять из описаний наборов правил, реализовав которые вы должны получить красиво-работающий продукт.
❓Но что, если вы не смогли чего-то учесть?
Тут на помощь приходит второй вариант постановки задачи
(ждите продолжения сегодня)…
В больших нетиповых проектах постановка и формирование ТЗ становится нетривиальной. Нужно описать много условий, ветвлений и прочих сложных логических конструкций, которые «с наскоку» не реализовать, ведь на бумаге это выглядит лишь как набор абстракций.
А так уж устроен наш мозг, что ему нужна конкретика и образы!💁👁
Взять, например, разработку фриланс-портала. У проекта обычно несколько статусов. Всякий статус доступен для пользователей с разными ролями, у каждой роли есть набор атрибутов и свойств, характерных только для этого статуса и этой роли. А еще есть дополнительные, вроде бы, автономные сущности такие как «Переписка», «Оплата», «Отзывы». Они вроде бы самостоятельные, но, так или иначе, перекликаются со статусами и ролями.
❗️ Все это при пересечении дает очень большой набор вариантов, который нужно запрограммировать.
Возникает вопрос, как подать информацию специалисту, чтобы она была действительно понятна и непротиворечива, и, желательно, наглядна?
Есть всего два возможных базовых варианта.
✅ Вариант 1. Подумать и сформулировать набор правил для каждой сущности.
Например, берем сущность «Переписка» и формулируем правила по ее доступности. Это может выглядеть следующим образом:
Если между специалистом и заказчиком была переписка, то она блокируется при следующих условиях:
a. Проект получает статус «Заблокирован»
b. Проект получает признак «Снят с публикации»
c. Проект получает статус «Закрыт» (полное закрытие)
d. Специалист отказался от выполнения проекта на этапе поиска исполнителя
На данном этапе важно, чтобы правилом покрывались все возможные варианты событий.
Если этого не произойдет, а программист не подумает самостоятельно (или не задаст вам вопросы), то вы можете получить достаточно неприятные сюрпризы на этапе приемки проекта.
⚠️ Кстати, как вы думаете, какой сюрприз (явно ненужный нам) можно получить по этому правилу? Напишите в комментариях, если заметите! 🤷
Когда вы формулируете такие правила важно донести до специалистов необходимость в их критичном восприятии! Если на этапе реализации они смогут увидеть несовершенства в формулировках, то должны дать вам немедленную обратную связь, чтобы уточнить правило.
Лайфхак: это лучше зафиксировать в проектной документации в качестве принципа работы!
Таким образом, ваше ТЗ будет состоять из описаний наборов правил, реализовав которые вы должны получить красиво-работающий продукт.
❓Но что, если вы не смогли чего-то учесть?
Тут на помощь приходит второй вариант постановки задачи
(ждите продолжения сегодня)…
👍1
...продолжение предыдущего поста.
✅ Вариант 2. Рассмотреть все частные случаи разрабатываемого процесса, разложив его на максимально подробные составляющие.
Здесь проблема состоит в том, что процесс в сложных системах может быть настолько большим, что представить его полным набором мелких составляющих, мягко говоря, затруднительно. А, порой, и вовсе невозможно.
Вот вам абстрактный пример. У нас есть:
▪️3 состояния проекта S = (S1, S2, S3),
▪️3 роли R = (R1, R2, R3)
▪️и три атрибута А = (А1, А2, А3), которые зависят от того, как пересекаются S и R.
По каким-то причинам нам трудно сформулировать общие правила, по которым мы должны запрограммировать систему. Поэтому мы просто должны описать все возможные пересечения этих комбинаций.
Например, мы подумали, и у нас получилось так:
S1 + R1 = А1
S1 + R2 = А2
S1 + R3 = А3
S2 + R1 = А1
S2 + R2 = А2
S2 + R3 = А3
S3 + R1 = А1
S3 + R2 = А2
S3 + R3 = А3
Таким образом, полное пересечение двух небольших множеств, состоящих всего из трех элементов дало нам выборку из 9 вариантов!
⚠️ А если множество статусов S получит еще статус S4? Сколько будет вариантов? Уже 12! А если размеры обоих множеств станут равны 4-м. Тогда вариантов будет 16!
Это я еще не привел пример, когда нам нужно пересечь 3 множества или больше!
К чему это я? К тому, что очень легко при таком подходе запутаться. А уж как сильно демотивируют программистов такие простыни описаний и как сильно взлетает стоимость проектов от этого – я скромно умалчиваю.
Выводы будут дальше. Пока осознайте, насколько вам близок этот подход😊
Есть вопросы? - Буду рад ответить на них в комментариях!
✅ Вариант 2. Рассмотреть все частные случаи разрабатываемого процесса, разложив его на максимально подробные составляющие.
Здесь проблема состоит в том, что процесс в сложных системах может быть настолько большим, что представить его полным набором мелких составляющих, мягко говоря, затруднительно. А, порой, и вовсе невозможно.
Вот вам абстрактный пример. У нас есть:
▪️3 состояния проекта S = (S1, S2, S3),
▪️3 роли R = (R1, R2, R3)
▪️и три атрибута А = (А1, А2, А3), которые зависят от того, как пересекаются S и R.
По каким-то причинам нам трудно сформулировать общие правила, по которым мы должны запрограммировать систему. Поэтому мы просто должны описать все возможные пересечения этих комбинаций.
Например, мы подумали, и у нас получилось так:
S1 + R1 = А1
S1 + R2 = А2
S1 + R3 = А3
S2 + R1 = А1
S2 + R2 = А2
S2 + R3 = А3
S3 + R1 = А1
S3 + R2 = А2
S3 + R3 = А3
Таким образом, полное пересечение двух небольших множеств, состоящих всего из трех элементов дало нам выборку из 9 вариантов!
⚠️ А если множество статусов S получит еще статус S4? Сколько будет вариантов? Уже 12! А если размеры обоих множеств станут равны 4-м. Тогда вариантов будет 16!
Это я еще не привел пример, когда нам нужно пересечь 3 множества или больше!
К чему это я? К тому, что очень легко при таком подходе запутаться. А уж как сильно демотивируют программистов такие простыни описаний и как сильно взлетает стоимость проектов от этого – я скромно умалчиваю.
Выводы будут дальше. Пока осознайте, насколько вам близок этот подход😊
Есть вопросы? - Буду рад ответить на них в комментариях!
👏1
🔰 Применимость на практике и "плавающие" ошибки.
Двумя постами выше, а именно здесь и здесь, мы рассмотрели два способа подачи информации для ТЗ в сложных проектах. Я считаю, что у обоих способов есть свои преимущества и недостатки.
Способ постановки задачи обобщенными правилами приближен к тому, как закладывают логику в свои решения программисты, но требует от нас предварительно проделать достаточно большой объем аналитической работы.
⚠️ Если эта работа проделана должным образом, то второй способ может и не понадобится.
Кстати, бывают случаи, когда правило видоизменяется по ходу проекта, например, если мы что-то не учли изначально или в проекте появляются новые вводные. Такое бывает по невнимательности или по Agile:)
Способ описания частных случаев считаю целесообразным тогда, когда у нас не получилось сформулировать однозначный набор общих правил или на этапе отладки решения мы увидели кучу ошибок, выходящих за границы изначально составленной формулы.
Этот способ позволяет зафиксировать уже работающие варианты решения, а также неработающие (или содержащие баги). Это особенно полезно, если возникают так называемые «плавающие» ошибки. Плавающая ошибка очень неприятна тем, что как бы исправив ее в одном частном случае, она вылезает в другом частном случае.😤
Другими словами это, когда:
▪️после проверки было: S1 + R1 = А2 (неправильно), а S1 + R2 = А2 (правильно)
▪️после исправления стало: S1 + R1 = А1 (правильно), а S1 + R2 = А1 (неправильно)
Таким образом, наша ошибка уплыла из случая S1 + R1, но приплыла в случай S1 + R2.
У некоторых программистов плавающие ошибки порождают иллюзию, что руководитель проекта придирается к реализации и «придумывает на ходу» новые вводные. В то время как виной всему на самом деле неправильно заданные правила, вызывающие миграцию багов из одного частного случая в другой.
Для руководителя проекта такие ошибки - страшный сон, ведь по мере столкновения с ними, возникает перспектива повторного тестирования всего проекта! В тоже время программист просто меняет условие в коде и ждет реакции.
ℹ️ Мой совет руководителям: фиксируйте состояние системы в частных случаях, чтобы показать, что где-то в коде заданы неверные логические условия, которые заставляют нашу ошибку переплывать с места на место.
При таком подходе снять с себя ответственность уже не получится, а это уже прямое указание на чью-то возможную некомпетентность или лень!⛔️
Понимаю, что вам, как руководителю, конечно, очень муторно описывать эти случаи и следить за ними. Частично или полностью эту задачу можно (и нужно!) поручить тестировщикам, но т.к. ответственность за проект несете вы - возможно именно вам придется в этом разобраться.
К сожалению квалификация некоторых тестировщиков или масштабы ветвлений все равно не позволят нам описать все частные случаи, которые могут встретиться на практике.
Так что здесь целесообразен только реальный пилотный запуск с постоянным мониторингом обратной связи от пользователей и латание дыр "на живую".
Иначе проект вы рискуете так никогда и не запустить.🤷
Буду рад, если вы поделитесь в комментариях своим опытом борьбы с плавающими ошибками! Как решали подобные ситуации? Были ли конфликты на этой почве?
Двумя постами выше, а именно здесь и здесь, мы рассмотрели два способа подачи информации для ТЗ в сложных проектах. Я считаю, что у обоих способов есть свои преимущества и недостатки.
Способ постановки задачи обобщенными правилами приближен к тому, как закладывают логику в свои решения программисты, но требует от нас предварительно проделать достаточно большой объем аналитической работы.
⚠️ Если эта работа проделана должным образом, то второй способ может и не понадобится.
Кстати, бывают случаи, когда правило видоизменяется по ходу проекта, например, если мы что-то не учли изначально или в проекте появляются новые вводные. Такое бывает по невнимательности или по Agile:)
Способ описания частных случаев считаю целесообразным тогда, когда у нас не получилось сформулировать однозначный набор общих правил или на этапе отладки решения мы увидели кучу ошибок, выходящих за границы изначально составленной формулы.
Этот способ позволяет зафиксировать уже работающие варианты решения, а также неработающие (или содержащие баги). Это особенно полезно, если возникают так называемые «плавающие» ошибки. Плавающая ошибка очень неприятна тем, что как бы исправив ее в одном частном случае, она вылезает в другом частном случае.😤
Другими словами это, когда:
▪️после проверки было: S1 + R1 = А2 (неправильно), а S1 + R2 = А2 (правильно)
▪️после исправления стало: S1 + R1 = А1 (правильно), а S1 + R2 = А1 (неправильно)
Таким образом, наша ошибка уплыла из случая S1 + R1, но приплыла в случай S1 + R2.
У некоторых программистов плавающие ошибки порождают иллюзию, что руководитель проекта придирается к реализации и «придумывает на ходу» новые вводные. В то время как виной всему на самом деле неправильно заданные правила, вызывающие миграцию багов из одного частного случая в другой.
Для руководителя проекта такие ошибки - страшный сон, ведь по мере столкновения с ними, возникает перспектива повторного тестирования всего проекта! В тоже время программист просто меняет условие в коде и ждет реакции.
ℹ️ Мой совет руководителям: фиксируйте состояние системы в частных случаях, чтобы показать, что где-то в коде заданы неверные логические условия, которые заставляют нашу ошибку переплывать с места на место.
При таком подходе снять с себя ответственность уже не получится, а это уже прямое указание на чью-то возможную некомпетентность или лень!⛔️
Понимаю, что вам, как руководителю, конечно, очень муторно описывать эти случаи и следить за ними. Частично или полностью эту задачу можно (и нужно!) поручить тестировщикам, но т.к. ответственность за проект несете вы - возможно именно вам придется в этом разобраться.
К сожалению квалификация некоторых тестировщиков или масштабы ветвлений все равно не позволят нам описать все частные случаи, которые могут встретиться на практике.
Так что здесь целесообразен только реальный пилотный запуск с постоянным мониторингом обратной связи от пользователей и латание дыр "на живую".
Иначе проект вы рискуете так никогда и не запустить.🤷
Буду рад, если вы поделитесь в комментариях своим опытом борьбы с плавающими ошибками! Как решали подобные ситуации? Были ли конфликты на этой почве?
Telegram
ПРО-продукт
🔰Если ты владелец IT-продукта и болеешь за свое дело, то без качественных технических заданий не обойтись.
В больших нетиповых проектах постановка и формирование ТЗ становится нетривиальной. Нужно описать много условий, ветвлений и прочих сложных логических…
В больших нетиповых проектах постановка и формирование ТЗ становится нетривиальной. Нужно описать много условий, ветвлений и прочих сложных логических…
👏1
🔰 Нужен ли промежуточный контроль задач?
Умение расставлять контрольные точки при делегировании задач отличает грамотного руководителя.
Поставить задачу и не осуществить промежуточный контроль означает:
◾Высокую вероятность получить незапланированный/неожиданный результат в конце срока.
◾Вероятность не получить результат вообще по причине того, что о задаче забыли, отложили, не поняли и не сделали и, ВНИМАНИЕ, посчитали не не важной ввиду отсутствия промежуточного контроля 😁
Отсутствие точек контроля, в принципе плохо, т.к. сильно расхолаживает коллектив.💣🚫
У большинства сотрудников возникает закономерный вопрос, зачем мне делать это, если начальник не интересуется делами, которые сам же назначил мне?🤦
Не стоит надеяться на исполнительность персонала, особенно, если вы почувствовали, что для выполнения задачи сотруднику может не хватить стандартной мотивации. Скорее всего, ваше чутье вас не обманет и без ваших управленческих пинков дело не пойдет.
Хуже, чем отсутствие контрольных точек может быть только то, что вы их поставите и сами же забудете!🤣 - Не делайте так!
Правильный алгоритм действий будет таким:
✅ Объяснить задачу. При необходимости предоставить материалы, инструкции и прочую документацию для выполнения.
✅ Выяснить все ли понятно, ответить на вопросы, если они будут.
✅ Предоставить полномочия и необходимые ресурсы для решения.
✅ Обозначить срок выполнения задачи. Возможен вариант, когда сотрудник сам обозначит такой срок и вы его зафиксируете.
✅ Хорошей практикой будет узнать, какие первые шаги сделает сотрудник для решения задачи.
✅ Обозначить контрольные точки для осмотра промежуточных результатов работы и коррекции дальнейших действий по необходимости.
✅ ОСУЩЕСТВИТЬ КОНТРОЛЬ В СООТВЕТСТВИИ С ПЛАНОМ‼️
Берите этот алгоритм себе и сверяйтесь с ним по мере необходимости.
И пусть невыполнимых задач станет меньше!
❓Кстати, было ли у вас такое, когда о ваших задачах забывали? К чему это приводило? Расскажите в комментариях!
Умение расставлять контрольные точки при делегировании задач отличает грамотного руководителя.
Поставить задачу и не осуществить промежуточный контроль означает:
◾Высокую вероятность получить незапланированный/неожиданный результат в конце срока.
◾Вероятность не получить результат вообще по причине того, что о задаче забыли, отложили, не поняли и не сделали и, ВНИМАНИЕ, посчитали не не важной ввиду отсутствия промежуточного контроля 😁
Отсутствие точек контроля, в принципе плохо, т.к. сильно расхолаживает коллектив.💣🚫
У большинства сотрудников возникает закономерный вопрос, зачем мне делать это, если начальник не интересуется делами, которые сам же назначил мне?🤦
Не стоит надеяться на исполнительность персонала, особенно, если вы почувствовали, что для выполнения задачи сотруднику может не хватить стандартной мотивации. Скорее всего, ваше чутье вас не обманет и без ваших управленческих пинков дело не пойдет.
Хуже, чем отсутствие контрольных точек может быть только то, что вы их поставите и сами же забудете!🤣 - Не делайте так!
Правильный алгоритм действий будет таким:
✅ Объяснить задачу. При необходимости предоставить материалы, инструкции и прочую документацию для выполнения.
✅ Выяснить все ли понятно, ответить на вопросы, если они будут.
✅ Предоставить полномочия и необходимые ресурсы для решения.
✅ Обозначить срок выполнения задачи. Возможен вариант, когда сотрудник сам обозначит такой срок и вы его зафиксируете.
✅ Хорошей практикой будет узнать, какие первые шаги сделает сотрудник для решения задачи.
✅ Обозначить контрольные точки для осмотра промежуточных результатов работы и коррекции дальнейших действий по необходимости.
✅ ОСУЩЕСТВИТЬ КОНТРОЛЬ В СООТВЕТСТВИИ С ПЛАНОМ‼️
Берите этот алгоритм себе и сверяйтесь с ним по мере необходимости.
И пусть невыполнимых задач станет меньше!
❓Кстати, было ли у вас такое, когда о ваших задачах забывали? К чему это приводило? Расскажите в комментариях!
👍2🔥1
🔰 Как реагировать на сотрудников, чтобы они не сели вам на шею? Отбиться от «обезьян» без демотивации, автократии и уничижения личности.
В прошлой публикации мы говорили о делегировании и необходимости промежуточного контроля задач.
И вот задача поставлена, правила разъяснены, регламенты получены. Казалось бы, все идет по плану – до контрольной точки еще далеко, но…
Сотрудник приходит к вам ранее назначенного часа и просит помощи или совета. Что делать?
Вроде бы ничего критичного, но:
❗️Вас отрывают от дел насущных.🤕 А у вас, как руководителя, их итак невпроворот.
‼️Совет, за которым пришел сотрудник, по существу не требуется, если бы он сам подумал над задачей чуть больше обычного.
Послать подальше будет неправильно, особенно, если вы обозначили порядок эскалации проблем на самого себя. Формально, сотрудник все сделал согласно предписаниям – ему нужна помощь и он об этом сообщает - обезьяна у вас.
Примечание: обезьяна - это не сотрудник (как можно было бы подумать😆), а известная идиома, обозначающая проблему на ваших плечах в виде обезьяны🐒
Это, по задумке, должно оградить вас от неправильного решения задачи и, как следствие, от кривого результата. Но на практике, может обернуться тем, что вас постоянно будут дергать по сущим пустякам, забирая все свободное время.⛔️⏱
⚠️ Важно правильно диагностировать данную ситуацию и принять верное управленческое решение.
Что же на самом деле может скрываться за этой ситуацией?
1️⃣ Неуверенность. Неопытность.
2️⃣ Недостаток компетенций.
3️⃣ Недостаток полномочий.
Как понять, что же сподвигло сотрудника на подход к вам именно сейчас?
✅ Решение простое. Спросите его, как бы он поступил, если бы вас не было рядом. Ждите ответа. 👂🧘
Далее варианты:
Если ответ поступает и вас он устраивает – похвалите сотрудника. Скажите что-то типа: «Да, достойное решение» или «Хммм… интересно». Может даже: «Классная идея! Я как-то упустил ее из виду. Молодец!»
☝️Лайфхак: Попросите накидать его не менее трех вариантов решения.
То, что сотрудник дал вам ответы, говорит о том, что перед вами случай неопытности или неуверенности. Здесь важна положительная обратная связь, подкрепление качественных мыслей о решении этой ситуации позитивным откликом с вашей стороны.
Опционально, можно подсказать сотруднику, как довести его решения до идеала. Когда он даст варианты, подытожьте: «Ну, смотри, ты сам все решил. Значит, в будущем, уже знаешь как действовать».🙂👍
Остальные варианты рассмотрим в следующем посте.📃
А пока - задача на засыпку.
Как думаете, что скрывается за вариантом "Если ответ поступает, но он вас не устраивает"?
Пишите в комментариях ваши варианты!👇
В прошлой публикации мы говорили о делегировании и необходимости промежуточного контроля задач.
И вот задача поставлена, правила разъяснены, регламенты получены. Казалось бы, все идет по плану – до контрольной точки еще далеко, но…
Сотрудник приходит к вам ранее назначенного часа и просит помощи или совета. Что делать?
Вроде бы ничего критичного, но:
❗️Вас отрывают от дел насущных.🤕 А у вас, как руководителя, их итак невпроворот.
‼️Совет, за которым пришел сотрудник, по существу не требуется, если бы он сам подумал над задачей чуть больше обычного.
Послать подальше будет неправильно, особенно, если вы обозначили порядок эскалации проблем на самого себя. Формально, сотрудник все сделал согласно предписаниям – ему нужна помощь и он об этом сообщает - обезьяна у вас.
Примечание: обезьяна - это не сотрудник (как можно было бы подумать😆), а известная идиома, обозначающая проблему на ваших плечах в виде обезьяны🐒
Это, по задумке, должно оградить вас от неправильного решения задачи и, как следствие, от кривого результата. Но на практике, может обернуться тем, что вас постоянно будут дергать по сущим пустякам, забирая все свободное время.⛔️⏱
⚠️ Важно правильно диагностировать данную ситуацию и принять верное управленческое решение.
Что же на самом деле может скрываться за этой ситуацией?
1️⃣ Неуверенность. Неопытность.
2️⃣ Недостаток компетенций.
3️⃣ Недостаток полномочий.
Как понять, что же сподвигло сотрудника на подход к вам именно сейчас?
✅ Решение простое. Спросите его, как бы он поступил, если бы вас не было рядом. Ждите ответа. 👂🧘
Далее варианты:
Если ответ поступает и вас он устраивает – похвалите сотрудника. Скажите что-то типа: «Да, достойное решение» или «Хммм… интересно». Может даже: «Классная идея! Я как-то упустил ее из виду. Молодец!»
☝️Лайфхак: Попросите накидать его не менее трех вариантов решения.
То, что сотрудник дал вам ответы, говорит о том, что перед вами случай неопытности или неуверенности. Здесь важна положительная обратная связь, подкрепление качественных мыслей о решении этой ситуации позитивным откликом с вашей стороны.
Опционально, можно подсказать сотруднику, как довести его решения до идеала. Когда он даст варианты, подытожьте: «Ну, смотри, ты сам все решил. Значит, в будущем, уже знаешь как действовать».🙂👍
Остальные варианты рассмотрим в следующем посте.📃
А пока - задача на засыпку.
Как думаете, что скрывается за вариантом "Если ответ поступает, но он вас не устраивает"?
Пишите в комментариях ваши варианты!👇
Telegram
ПРО-продукт
🔰 Нужен ли промежуточный контроль задач?
Умение расставлять контрольные точки при делегировании задач отличает грамотного руководителя.
Поставить задачу и не осуществить промежуточный контроль означает:
◾Высокую вероятность получить незапланированный/неожиданный…
Умение расставлять контрольные точки при делегировании задач отличает грамотного руководителя.
Поставить задачу и не осуществить промежуточный контроль означает:
◾Высокую вероятность получить незапланированный/неожиданный…
👍4