Читаем состав трудовых действий:
• Анализ возможностей реализации требований к программному обеспечению
• Оценка времени и трудоемкости реализации требований к программному обеспечению
• Согласование требований к программному обеспечению с заинтересованными сторонами
• Оценка и согласование сроков выполнения поставленных задач
И необходимые умения:
• Проводить анализ исполнения требований
• Вырабатывать варианты реализации требований
• Проводить оценку и обоснование рекомендуемых решений
• Осуществлять коммуникации с заинтересованными сторонами
Здесь на первый план выходят социально-ориентированные навыки специалиста: умение общаться, задавать вопросы, вести дискуссию, в чем-то отстаивать свою позицию, где-то прислушаться к иной позиции. 👋
Нетрудно заметить, что из 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
... начало 👆
Если ответ поступает, но он вас не устраивает. Или ответа не следует. Здесь уже случай серьезнее.
Либо вопрос действительно обстоятельный, либо с вами играют в дурака (тут надо задуматься о целях такой игры), либо перед вами пример некомпетентности.
🧠Оцените ситуацию. Вспомните, встречалась ли данная проблема ранее в практике вашей компании. Есть ли люди, кто успешно ее решал? Где зафиксировано данное решение? Возможно, оно есть в каких-то инструкциях, чек-листах или в базе знаний?
▪️Если случай действительно новый и нигде не описан, то это повод обсудить эту ситуацию, оказать помощь и включить решение в базу знаний.
▪️ Проблема известна. Описание решения доступно. Сотрудник НЕ осведомлен. Прямо спросите у сотрудника, что говорят ваши регламенты и база знаний об этой ситуации. Вы же ознакамливали с ними сотрудника? Проводили обучение?
Если такое обучение не проводилось, то это ваше упущение как управленца 💀– запишите сотрудника на обучающий семинар или лично проведите экскурс по регламенту с описанием данного кейса. Поставьте ситуацию на контроль.🖊
Отныне, ваша управленческая задача – проверить результаты обучения, иначе ситуация будет воспроизводиться заново, может быть в других контекстах.
▪️Проблема известна. Описание решения доступно. Сотрудник был осведомлен. Когда вы понимаете, что сотрудник не знает регламент (при этом проходил обучение и знать его должен) или не потрудился воспользоваться базой знаний, но абсолютно уверены, что описание данного кейса там присутствует – отправьте его на поиск и изучение вопроса.
✔️При этом, укажите, что после того как сотрудник найдет решение, ему необходимо доложить об этом вам.📞
✔️Зафиксируйте договоренности в виде задачи в вашей CRM или письмом. 📩
✔️Укажите, что в аналогичных ситуациях ему необходимо впредь обращаться сначала к базе знаний, а потом – к вам. 📖
Если ситуация повторится, обсудите с ним вопрос переобучения. Повторится еще раз – поставьте вопрос о некомпетентности с последующим увольнением.🚷
Случай, с нехваткой полномочий обычно вырисовывается из ответа, который вас не устраивает. При этом бывает вариант, когда полномочия у сотрудника все же есть, просто ему страшно их использовать, ввиду необходимости согласований или новой непривычной для себя роли лидера. В данной ситуации напомните сотруднику о них и вернитесь к кейсу «Неуверенность/неопытность».
Если же вы поставили задачу, но не дали полномочий, то это ваш управленческий факап. 👀
Исправьте ситуацию – объясните сотруднику его новые права и обязанности. Уведомите всех, кто теперь должен взаимодействовать с сотрудником по новым правилам.
Выводы:
✅ Не допускайте пожирания вашего личного времени некомпетентными сотрудниками – отправляйте их на самостоятельный поиск информации или переобучение, контролируйте результат.
✅ Особенно-ленивых и неавтономных – увольняйте.
✅ Помогайте неопытным и неуверенным, максимально поощряя их самостоятельность в поисках решений известных вопросов.
✅ Фиксируйте ваши управленческие промахи и работайте над ними.
✅ Актуализируйте базу знаний компании. Выделите отдельный процесс и ответственных за ее наполнение.
Наш канал в ДЗЕН: https://zen.yandex.ru/productmaster
Если ответ поступает, но он вас не устраивает. Или ответа не следует. Здесь уже случай серьезнее.
Либо вопрос действительно обстоятельный, либо с вами играют в дурака (тут надо задуматься о целях такой игры), либо перед вами пример некомпетентности.
🧠Оцените ситуацию. Вспомните, встречалась ли данная проблема ранее в практике вашей компании. Есть ли люди, кто успешно ее решал? Где зафиксировано данное решение? Возможно, оно есть в каких-то инструкциях, чек-листах или в базе знаний?
▪️Если случай действительно новый и нигде не описан, то это повод обсудить эту ситуацию, оказать помощь и включить решение в базу знаний.
▪️ Проблема известна. Описание решения доступно. Сотрудник НЕ осведомлен. Прямо спросите у сотрудника, что говорят ваши регламенты и база знаний об этой ситуации. Вы же ознакамливали с ними сотрудника? Проводили обучение?
Если такое обучение не проводилось, то это ваше упущение как управленца 💀– запишите сотрудника на обучающий семинар или лично проведите экскурс по регламенту с описанием данного кейса. Поставьте ситуацию на контроль.🖊
Отныне, ваша управленческая задача – проверить результаты обучения, иначе ситуация будет воспроизводиться заново, может быть в других контекстах.
▪️Проблема известна. Описание решения доступно. Сотрудник был осведомлен. Когда вы понимаете, что сотрудник не знает регламент (при этом проходил обучение и знать его должен) или не потрудился воспользоваться базой знаний, но абсолютно уверены, что описание данного кейса там присутствует – отправьте его на поиск и изучение вопроса.
✔️При этом, укажите, что после того как сотрудник найдет решение, ему необходимо доложить об этом вам.📞
✔️Зафиксируйте договоренности в виде задачи в вашей CRM или письмом. 📩
✔️Укажите, что в аналогичных ситуациях ему необходимо впредь обращаться сначала к базе знаний, а потом – к вам. 📖
Если ситуация повторится, обсудите с ним вопрос переобучения. Повторится еще раз – поставьте вопрос о некомпетентности с последующим увольнением.🚷
Случай, с нехваткой полномочий обычно вырисовывается из ответа, который вас не устраивает. При этом бывает вариант, когда полномочия у сотрудника все же есть, просто ему страшно их использовать, ввиду необходимости согласований или новой непривычной для себя роли лидера. В данной ситуации напомните сотруднику о них и вернитесь к кейсу «Неуверенность/неопытность».
Если же вы поставили задачу, но не дали полномочий, то это ваш управленческий факап. 👀
Исправьте ситуацию – объясните сотруднику его новые права и обязанности. Уведомите всех, кто теперь должен взаимодействовать с сотрудником по новым правилам.
Выводы:
✅ Не допускайте пожирания вашего личного времени некомпетентными сотрудниками – отправляйте их на самостоятельный поиск информации или переобучение, контролируйте результат.
✅ Особенно-ленивых и неавтономных – увольняйте.
✅ Помогайте неопытным и неуверенным, максимально поощряя их самостоятельность в поисках решений известных вопросов.
✅ Фиксируйте ваши управленческие промахи и работайте над ними.
✅ Актуализируйте базу знаний компании. Выделите отдельный процесс и ответственных за ее наполнение.
Наш канал в ДЗЕН: https://zen.yandex.ru/productmaster
Дзен
ПРО-продукт
Канал для менеджеров проектов, владельцев бизнеса и управленцев, а также всех, кто относит себя к продуктологам и желает создавать качественные web-продукты.
👍2
🔰Прием «коктейль из проблем» и что с ним делать? Или как сотрудники прячут проебы факты в лапше с навозом, прикрывая свой зад.
Одной из самых иезуитских техник самозащиты от руководителя в корпоративной среде является техника, которую я называю «коктейль из проблем». 🍸💩
Многие сотрудники владеют ей в совершенстве, а неопытные руководители теряются, не зная, как ей противостоять.💀
Как это выглядит? Вы поставили сотруднику задачу, отбились от обезьян, но как только пришла пора требовать результат, столкнулись с бесконечным количеством оправданий и объяснений, почему его нет.
Для коктейля проблем характерны следующие признаки:
▪️Вам говорят о разведенной бурной деятельности в настоящем времени, но ни одно из названных действий прямо не относится к результату.🏋️♀️
▪️Оправдания подаются одним большим комом и представляют собой «сложные обстоятельства». Они взаимоувязаны и могут перекрывать друг друга в самых причудливых комбинациях. Обычно преподносятся с выгодой для себя.🏔
▪️Популярные ингредиенты коктейля: «высокая загрузка», «множество поручений», «вновь открывшиеся обстоятельства», «сделал, но остались мелочи» и разного рода неожиданности.🚴
Задача коктейля проблем увести фокус внимания руководителя в сторону от результата, выбить себе максимум поблажек и сохранить статус-кво.
В чем опасность коктейля для управленца? Попытка обсуждения проблем может затянуть неопытного руководителя в пучину безнадеги. В сердцах, он может плюнуть на это и сделать все сам, т.к. в моменте это может быть проще и быстрее, чем разбирать ситуацию.
⚠️ Это будет большой управленческой ошибкой, т.к. чревато тем, что сотрудник запомнит такое поведение как допустимое и будет им пользоваться в аналогичных ситуациях – станет неуправляемым!
Но не все так однозначно. Дилемма руководителя, состоит в том, что если в коктейле есть реальные проблемы, а такое иногда случается, и он их проигнорирует, продолжая требовать результат, то сотрудник будет демотивирован и, возможно, получит выгорание. А там недолго и до выхода из проекта или увольнения.🫤
Продолжение следует...
Одной из самых иезуитских техник самозащиты от руководителя в корпоративной среде является техника, которую я называю «коктейль из проблем». 🍸💩
Многие сотрудники владеют ей в совершенстве, а неопытные руководители теряются, не зная, как ей противостоять.💀
Как это выглядит? Вы поставили сотруднику задачу, отбились от обезьян, но как только пришла пора требовать результат, столкнулись с бесконечным количеством оправданий и объяснений, почему его нет.
Для коктейля проблем характерны следующие признаки:
▪️Вам говорят о разведенной бурной деятельности в настоящем времени, но ни одно из названных действий прямо не относится к результату.🏋️♀️
▪️Оправдания подаются одним большим комом и представляют собой «сложные обстоятельства». Они взаимоувязаны и могут перекрывать друг друга в самых причудливых комбинациях. Обычно преподносятся с выгодой для себя.🏔
▪️Популярные ингредиенты коктейля: «высокая загрузка», «множество поручений», «вновь открывшиеся обстоятельства», «сделал, но остались мелочи» и разного рода неожиданности.🚴
Задача коктейля проблем увести фокус внимания руководителя в сторону от результата, выбить себе максимум поблажек и сохранить статус-кво.
В чем опасность коктейля для управленца? Попытка обсуждения проблем может затянуть неопытного руководителя в пучину безнадеги. В сердцах, он может плюнуть на это и сделать все сам, т.к. в моменте это может быть проще и быстрее, чем разбирать ситуацию.
⚠️ Это будет большой управленческой ошибкой, т.к. чревато тем, что сотрудник запомнит такое поведение как допустимое и будет им пользоваться в аналогичных ситуациях – станет неуправляемым!
Но не все так однозначно. Дилемма руководителя, состоит в том, что если в коктейле есть реальные проблемы, а такое иногда случается, и он их проигнорирует, продолжая требовать результат, то сотрудник будет демотивирован и, возможно, получит выгорание. А там недолго и до выхода из проекта или увольнения.🫤
Продолжение следует...
Telegram
ПРО-продукт
🔰Если ты владелец IT-продукта и болеешь за свое дело, то без качественных технических заданий не обойтись.
В больших нетиповых проектах постановка и формирование ТЗ становится нетривиальной. Нужно описать много условий, ветвлений и прочих сложных логических…
В больших нетиповых проектах постановка и формирование ТЗ становится нетривиальной. Нужно описать много условий, ветвлений и прочих сложных логических…
👍4
... в продолжение темы "Коктейль из проблем"
Пример «коктейля проблем»
- Иван, как дела по-нашему проект? Каков результат?
- Еще в работе. Не переносил на сервер. Пытаюсь ветки доклеить, т.к. много пунктов красных я правил. Скорее всего, сегодня завершу все. Правки в двух ветках перетерлись, когда конфликты решал. И завтра также буду в ночь работать. Вчера удалось с одним разобраться, стартую самый злостный баг.
Наблюдаем типичнуюкучу говна кашу из проблем: повествование в настоящем времени, скачкообразная подача обстоятельств и объяснений на тему «почему не сделано», смещение фокуса внимания с результата на проблемы и бурная деятельность по их решению.
Что же делать?
Как и при решении многих других управленческих задач, тут важен принцип «разделяй и властвуй». Нам нужно «расщепить» коктейль на составляющие и работать с каждым ингредиентом порознь.
Каждый ингредиент-проблема обычно легко решаема сама по себе, если не давать сотруднику слишком вольно манипулировать фактами.
К каждому ингредиенту полезно применить следующие приемы из поста отбиться от обезьян:
✔️Как ты мог решить это?
✔️Это прописано в твоих инструкциях/регламентах?
✔️Ты владеешь полномочиями, чтобы устранить это?
Разбор нашей ситуации
Если вернуться к нашему примеру, то мы можем разбить его на следующие составляющие:
▪️Проблема с ветками.
▪️Проблема злостного бага.
▪️Не переносил на сервер.
▪️Между строк: не уведомил всех заинтересованных лиц об имеющихся препятствиях. Как следствиепросрал сорвал срок.
Начнем с уведомления, т.к. это проще всего. Принципы коммуникации в проекте зафиксированы документально и там написано о необходимости превентивного уведомления о задержках? – Да. Уведомление последовало? – Нет!
Значит, в качестве немедленного управленческого воздействия должен последовать выговор. 📢 Здесь - порешали!
Проблема с ветками может являться проблемой недостатка компетенций или нехватки времени. Если на вопрос «Как ты мог решить это?», приходит понимание о компетенциях, то на проект можно выделить более квалифицированного помощника. Спеца, замешавшего коктейль, направить на обучение. Тоже порешали!
〰️〰️〰️
Важная ремарка
Типична ситуация, когда сотрудник отмазывается нехваткой времени ввиду «множества других задач», которые навалились на него.
В этом случае руководитель должен:
1️⃣ Свериться с отчетом сотрудника о выполненных задачах. У вас нет такого отчета? – Немедленно внедрите его или настройте учет задач в CRM. Может обнаружиться, что среди выполняемых задач не было более срочных и важных чем та, которая зафакаплена. Разберите с сотрудником приоритеты и сделайте выговор, если они были нарушены.
2️⃣ Сделать организационные выводы. Если график сотрудника действительно забит и у него есть реальный перегруз в работе, будет логичным найти ему помощника или распределить его обязанности по другим сотрудникам.
〰️〰️〰️
Злостный баг и перенос на сервер решаются по аналогии проблемы с ветками, принимая во внимание их происхождение – будь то компетенции или время.
Итогом решения нашей проблемы стал выговор сотруднику, что подстрахует нас в будущем от ее повторения, и выделение новых ресурсов на выполнение задачи.
Коктейль взболтали, но больше не смешиваем!🙂
❓А вы когда-нибудь сталкивались с подобными ситуациями? Как разбирали их?
Пример «коктейля проблем»
- Иван, как дела по-нашему проект? Каков результат?
- Еще в работе. Не переносил на сервер. Пытаюсь ветки доклеить, т.к. много пунктов красных я правил. Скорее всего, сегодня завершу все. Правки в двух ветках перетерлись, когда конфликты решал. И завтра также буду в ночь работать. Вчера удалось с одним разобраться, стартую самый злостный баг.
Наблюдаем типичную
Что же делать?
Как и при решении многих других управленческих задач, тут важен принцип «разделяй и властвуй». Нам нужно «расщепить» коктейль на составляющие и работать с каждым ингредиентом порознь.
Каждый ингредиент-проблема обычно легко решаема сама по себе, если не давать сотруднику слишком вольно манипулировать фактами.
К каждому ингредиенту полезно применить следующие приемы из поста отбиться от обезьян:
✔️Как ты мог решить это?
✔️Это прописано в твоих инструкциях/регламентах?
✔️Ты владеешь полномочиями, чтобы устранить это?
Разбор нашей ситуации
Если вернуться к нашему примеру, то мы можем разбить его на следующие составляющие:
▪️Проблема с ветками.
▪️Проблема злостного бага.
▪️Не переносил на сервер.
▪️Между строк: не уведомил всех заинтересованных лиц об имеющихся препятствиях. Как следствие
Начнем с уведомления, т.к. это проще всего. Принципы коммуникации в проекте зафиксированы документально и там написано о необходимости превентивного уведомления о задержках? – Да. Уведомление последовало? – Нет!
Значит, в качестве немедленного управленческого воздействия должен последовать выговор. 📢 Здесь - порешали!
Проблема с ветками может являться проблемой недостатка компетенций или нехватки времени. Если на вопрос «Как ты мог решить это?», приходит понимание о компетенциях, то на проект можно выделить более квалифицированного помощника. Спеца, замешавшего коктейль, направить на обучение. Тоже порешали!
〰️〰️〰️
Важная ремарка
Типична ситуация, когда сотрудник отмазывается нехваткой времени ввиду «множества других задач», которые навалились на него.
В этом случае руководитель должен:
1️⃣ Свериться с отчетом сотрудника о выполненных задачах. У вас нет такого отчета? – Немедленно внедрите его или настройте учет задач в CRM. Может обнаружиться, что среди выполняемых задач не было более срочных и важных чем та, которая зафакаплена. Разберите с сотрудником приоритеты и сделайте выговор, если они были нарушены.
2️⃣ Сделать организационные выводы. Если график сотрудника действительно забит и у него есть реальный перегруз в работе, будет логичным найти ему помощника или распределить его обязанности по другим сотрудникам.
〰️〰️〰️
Злостный баг и перенос на сервер решаются по аналогии проблемы с ветками, принимая во внимание их происхождение – будь то компетенции или время.
Итогом решения нашей проблемы стал выговор сотруднику, что подстрахует нас в будущем от ее повторения, и выделение новых ресурсов на выполнение задачи.
Коктейль взболтали, но больше не смешиваем!🙂
❓А вы когда-нибудь сталкивались с подобными ситуациями? Как разбирали их?
Telegram
ПРО-продукт
🔰Прием «коктейль из проблем» и что с ним делать? Или как сотрудники прячут проебы факты в лапше с навозом, прикрывая свой зад.
Одной из самых иезуитских техник самозащиты от руководителя в корпоративной среде является техника, которую я называю «коктейль…
Одной из самых иезуитских техник самозащиты от руководителя в корпоративной среде является техника, которую я называю «коктейль…
👍5
Я много работаю с программистами. 👨💻
И есть у меня привычка - отзывы собирать. Ну, прежде чем взять человека в команду, проверяю его по разным источникам, чтобы не получить какой-то нежданчик.
Дело в том, что многие программисты по сути своей - интроверты. На прямой вопрос - "А можно ли у кого-то получить отзыв на вас?" - тушуются. Некоторые говорят что-то про NDA и тому подобное. Сливаются в общем.
А проверить человека хочется!
✅ Ваша задача в этом случае выудить из кандидата хотя бы один работающий проект (сайт). Ну, если прямо все под NDA - это очень подозрительно - таких брать в команду рискованно.
Далее вы лезете на этот сайт в поисках хоть каких контактов. Их бывает найти тяжело, но тогда меня выручает какое-нибудь пользовательское соглашение, где всегда (ну по закону так должно быть!), есть контакт. Обычно это емэйл, реже - телефон.
Ваша задача написать на этот емэйл запрос. Я обычно пишу как-то так.
➖➖➖➖➖
Здравствуйте!
Мы ищем исполнителя (программиста) для нашего проекта по доработке сайта на Laravel. И нам откликнулся некийВасильков Василий Васечкин
В личной беседе с ним в телеграм он скинул ваш сайт:https://сайткоторыйвамудалосьнайти.рф в качестве проекта, который он реализовал.
Могли бы вы дать отзыв о нем?
1. Знаете ли вы такого человека?
2. В какой части он реализовал ваш проект? Полностью/частично?
3. Что хорошего можете сказать о нем?
4. Пропадал ли он со связи? Были ли трудности в общении? Странные ситуации
5. Как со сроками?
Буду благодарен за любую обратную связь о нем!
Если у вас есть встречные вопросы ко мне, то с удовольствием переговорю с вами по телефону.
Успехов в вашем деле!
[Подпись и телефон]
➖➖➖➖➖
⚠️ Обратную связь на такой запрос дают в 9/10 случаев. И это то, что вам нужно.
Вы скажете: "Спасибо, Кэп!" - Не благодарите. Что-то мне подсказывает, что этим пользуются немногие. Или я ошибаюсь?
Пишите в комментариях, проверяете ли ваших кандидатов таким образом? Получаете обратную связь?
И есть у меня привычка - отзывы собирать. Ну, прежде чем взять человека в команду, проверяю его по разным источникам, чтобы не получить какой-то нежданчик.
Дело в том, что многие программисты по сути своей - интроверты. На прямой вопрос - "А можно ли у кого-то получить отзыв на вас?" - тушуются. Некоторые говорят что-то про NDA и тому подобное. Сливаются в общем.
А проверить человека хочется!
✅ Ваша задача в этом случае выудить из кандидата хотя бы один работающий проект (сайт). Ну, если прямо все под NDA - это очень подозрительно - таких брать в команду рискованно.
Далее вы лезете на этот сайт в поисках хоть каких контактов. Их бывает найти тяжело, но тогда меня выручает какое-нибудь пользовательское соглашение, где всегда (ну по закону так должно быть!), есть контакт. Обычно это емэйл, реже - телефон.
Ваша задача написать на этот емэйл запрос. Я обычно пишу как-то так.
➖➖➖➖➖
Здравствуйте!
Мы ищем исполнителя (программиста) для нашего проекта по доработке сайта на Laravel. И нам откликнулся некий
В личной беседе с ним в телеграм он скинул ваш сайт:
Могли бы вы дать отзыв о нем?
1. Знаете ли вы такого человека?
2. В какой части он реализовал ваш проект? Полностью/частично?
3. Что хорошего можете сказать о нем?
4. Пропадал ли он со связи? Были ли трудности в общении? Странные ситуации
5. Как со сроками?
Буду благодарен за любую обратную связь о нем!
Если у вас есть встречные вопросы ко мне, то с удовольствием переговорю с вами по телефону.
Успехов в вашем деле!
[Подпись и телефон]
➖➖➖➖➖
⚠️ Обратную связь на такой запрос дают в 9/10 случаев. И это то, что вам нужно.
Вы скажете: "Спасибо, Кэп!" - Не благодарите. Что-то мне подсказывает, что этим пользуются немногие. Или я ошибаюсь?
Пишите в комментариях, проверяете ли ваших кандидатов таким образом? Получаете обратную связь?
🔥4👍2
🔰 Что такое упоротый профессионализм?
Понадобился мне однажды дизайнер на проект. Задача состояла в том, чтобы отрисовать страницы для нового (это важно!) раздела сайта. Дизайн надо было сделать с учетом современных трендов, при этом сохранить стилистическую преемственность с уже существующим блоком. Дополнительно внести интерактив, чтобы понимать, как будет выглядеть путь пользователя в новом разделе.
Когда мне попался дизайнер, условно назовем его Виктор, я был просто в восторге от его работ. Я осмотрел его портфолио и понял – он тот человек, кто мне нужен. Там было все то, что мне требовалось: воздушность, эргономичность, стилистическая полнота, прослеживались структура и удобство. Все это было более чем актуальным и я практически не размышлял над тем, заключать с ним договор или нет.
Мы созвонились с Виктором по скайпу и я объяснил ему задачу. В беседе он задавал грамотные вопросы, демонстрировал активную профессиональную позицию и был, в целом, инициативен и внимателен к моим пожеланиям.
Мне казалось, что мы договорились, но через некоторое время Виктор снова позвонил мне и настоятельно посоветовал начать делать дизайн с главной страницы сайта. Не нужного мне раздела, а именно сайта!
Он сказал, что проанализировал его и нашел ряд непозволительных дизайнерских ошибок, которые надо исправить. И привел несколько примеров, где часть элементов была не в сетке, часть элементов использовалась не по назначению и прочие подобные моменты.🙈
На это я резонно заметил, что этого делать не надо было: эти ошибки мне, во-первых, известны, во-вторых, касаются той части проекта, работа с которой сейчас не требуется и не финансируется заказчиком.
Я еще раз обратил внимание Виктора, что работать нужно именно с новым разделом, но уже не допуская подобных ошибок, которые были поставлены мне в пример.
Виктор согласился со мной, но почему-то теперь стал настаивать на внесении полного аванса за весь проект целиком, который оценил в немалую (выше, чем по рынку) сумму. Логика была такая – если проект содержит много «ошибок», то и цена за их «исправление» будет соответствующая.
Я не стал спорить и согласился с его ценой, но попросил начать работу с оформления основной страницы раздела, чтобы понять насколько хорошо он осознал задачу. Потом я благодарил себя за это решение!
‼️ Я внес аванс за эту страницу и через 3 дня Виктор предоставил мне макет. И это была… Главная страница всего сайта, которую он все же переделал, как считал нужным.🤬
Он объяснил это тем, что не мог поступить по-другому, т.к., вопреки моим увещеваниям, счел неправильным, непрофессиональным и, следовательно, невозможным начать делать дизайн с нужного мне раздела, не исправив главную.
Такое поведение я называю «упоротый профессионализм». Благодаря Виктору и похожим «специалистам» я выделил характерные для него черты поведения:
⛔️ Ставят свое мнение и амбиции на первый план. Зачастую, против интересов проекта. Вы можете хотеть сделать дизайн новой страницы, а дизайнер - добавить крутую работу в свое портфолио, обучиться за ваш счет новому инструменту или технологии и т.п.
⛔️ Сильно задирают ценник, когда с ними не соглашаются. Так они компенсируют недостаток мотивации в работе с «тупым заказчиком». Цена остается единственной интересной для них движущей силой проекта. Но не адекватной.
⛔️ Склоны переоценивать свои заслуги. Выдают оплошности за свершенное в интересах заказчика благо, которое он, в силу множества причин, не в силах осознать самостоятельно. Иногда апеллируют к чувству вины - "Верну деньги, если вы считаете, что поступаете правильно" (в смысле, что требуете их назад заговно ненужный результат).
⛔️ На переговорах с ними вы незаметно для себя уклоняетесь от намеченных целей. Ваше внутренне ощущение можно описать словами «тут что-то не так». Верьте ему!
⛔️ Перфекционизм - одна из составляющих упоротого профессионализма. Делать бесконечно хорошо, когда вам это совсем не нужно.
〰️〰️〰️
А вы встречались с проявлениями упоротого профессионализма? Как реагировали? Напишите в комментариях.
Понадобился мне однажды дизайнер на проект. Задача состояла в том, чтобы отрисовать страницы для нового (это важно!) раздела сайта. Дизайн надо было сделать с учетом современных трендов, при этом сохранить стилистическую преемственность с уже существующим блоком. Дополнительно внести интерактив, чтобы понимать, как будет выглядеть путь пользователя в новом разделе.
Когда мне попался дизайнер, условно назовем его Виктор, я был просто в восторге от его работ. Я осмотрел его портфолио и понял – он тот человек, кто мне нужен. Там было все то, что мне требовалось: воздушность, эргономичность, стилистическая полнота, прослеживались структура и удобство. Все это было более чем актуальным и я практически не размышлял над тем, заключать с ним договор или нет.
Мы созвонились с Виктором по скайпу и я объяснил ему задачу. В беседе он задавал грамотные вопросы, демонстрировал активную профессиональную позицию и был, в целом, инициативен и внимателен к моим пожеланиям.
Мне казалось, что мы договорились, но через некоторое время Виктор снова позвонил мне и настоятельно посоветовал начать делать дизайн с главной страницы сайта. Не нужного мне раздела, а именно сайта!
Он сказал, что проанализировал его и нашел ряд непозволительных дизайнерских ошибок, которые надо исправить. И привел несколько примеров, где часть элементов была не в сетке, часть элементов использовалась не по назначению и прочие подобные моменты.🙈
На это я резонно заметил, что этого делать не надо было: эти ошибки мне, во-первых, известны, во-вторых, касаются той части проекта, работа с которой сейчас не требуется и не финансируется заказчиком.
Я еще раз обратил внимание Виктора, что работать нужно именно с новым разделом, но уже не допуская подобных ошибок, которые были поставлены мне в пример.
Виктор согласился со мной, но почему-то теперь стал настаивать на внесении полного аванса за весь проект целиком, который оценил в немалую (выше, чем по рынку) сумму. Логика была такая – если проект содержит много «ошибок», то и цена за их «исправление» будет соответствующая.
Я не стал спорить и согласился с его ценой, но попросил начать работу с оформления основной страницы раздела, чтобы понять насколько хорошо он осознал задачу. Потом я благодарил себя за это решение!
‼️ Я внес аванс за эту страницу и через 3 дня Виктор предоставил мне макет. И это была… Главная страница всего сайта, которую он все же переделал, как считал нужным.🤬
Он объяснил это тем, что не мог поступить по-другому, т.к., вопреки моим увещеваниям, счел неправильным, непрофессиональным и, следовательно, невозможным начать делать дизайн с нужного мне раздела, не исправив главную.
Такое поведение я называю «упоротый профессионализм». Благодаря Виктору и похожим «специалистам» я выделил характерные для него черты поведения:
⛔️ Ставят свое мнение и амбиции на первый план. Зачастую, против интересов проекта. Вы можете хотеть сделать дизайн новой страницы, а дизайнер - добавить крутую работу в свое портфолио, обучиться за ваш счет новому инструменту или технологии и т.п.
⛔️ Сильно задирают ценник, когда с ними не соглашаются. Так они компенсируют недостаток мотивации в работе с «тупым заказчиком». Цена остается единственной интересной для них движущей силой проекта. Но не адекватной.
⛔️ Склоны переоценивать свои заслуги. Выдают оплошности за свершенное в интересах заказчика благо, которое он, в силу множества причин, не в силах осознать самостоятельно. Иногда апеллируют к чувству вины - "Верну деньги, если вы считаете, что поступаете правильно" (в смысле, что требуете их назад за
⛔️ На переговорах с ними вы незаметно для себя уклоняетесь от намеченных целей. Ваше внутренне ощущение можно описать словами «тут что-то не так». Верьте ему!
⛔️ Перфекционизм - одна из составляющих упоротого профессионализма. Делать бесконечно хорошо, когда вам это совсем не нужно.
〰️〰️〰️
А вы встречались с проявлениями упоротого профессионализма? Как реагировали? Напишите в комментариях.
👍4