Звучит разумно и согласен, обыденно для реактивного способа решения проблем в ширину. Наверно, именно реактивность отталкивает, так как говорит о запоздалой реакции. При наличии реактивных предпосылок совершенно не факт, что именно на них нужно реагировать, так как это не приведёт к решению проблемы по-существу, решит ее только фактологически и мы всё ещё будем отставать на пару шагов от решения реальной проблемы, которую никогда не решишь находясь в той же системе координат. Вот и вопрос, как перейти от реактивного ответа к проактивный инициативе, которая и способна качественно решить проблему, а не переливать из пустого в порожнее.
Вопрос, как раз, о промежутке между кому-то что-то не нравится и действии. Как понять, что проблема существует, прежде чем приняться менять что-то. Заявление одного или даже всех о недовольстве говорит только, как мы согласились, о их неудовлетворенности, а удовлетворить всех — утопия и не может быть целью. То есть, возвращаясь к моему комментарию, проблема несоответствия А и Б, желаемого и реального результата, решаема только, если эти А и Б известны. Если ожидаемый результат неизвестен, то проблема не может считаться решаемой. Переливание из пустого в порожнее.
Либо же как вариант, один из других способов решения проблем, не фактологический, а, например, векторный, когда выбирается поступательное движение в предпочтительную, например, интуитивно, сторону решения проблемной ситуации. Движение в сторону верных решений, как раз, не смотря, на недовольство кого-то там со стороны.
В общем смысле, если кому-то, даже всем, что-то не нравится, это говорит только, что им это не нравится. Это совсем не говорит, что что-то нужно менять. Неужели вы будете менять что-то всякий раз, когда кому-то, даже Вам, что-то не нравится? Это же путь к неврастении. А вот спрашивать «почему» целесообразно, согласен. Что после «почему?»
Да, но только если эта болезнь существует. Признание болезни, которой нет, — первый шаг, в лучшем случае, к самообману. Вопрос был как раз, как определяется наличие проблемы, чтобы отличить ее от домыслия.
Спасибо, интересная статья об очень изящном способе решения задач. Правило ли это, что чем изящнее способ алгоритмизования, тем сложнее его поддерживать? Описанный способ вмещает в себя симметричную рекуррентную вложенность, наверно, чрезвычайно трудоемкий в поддержке?
Риски и недостатки такого вида управления проектами же не говорит о его отсутствии. Существует много компаний, которые продолжают подобную практику с небольшими проектами. Отсюда и возникают такие цифры. Из полезного такая практика может хорошо научить приоритизация и мультизадачности. Хотя может и не научить.
Есть ещё небольшие проекты, и совсем маленькие. Я когда-то по
1. Вашим
2. Нашим
3. И вашим и нашим
4. Решать определенные проектные проблемы, руководясь тактическими целями
5. Добиваться стратегических целей
6. Формировать стратегические цели развития (проекта, продукта, портфолио)
7. Что может быть на этом месте?
Спасибо за ответ. Получается, что Вы прошли схему джун-миддл-сеньор вне аутсорсинга, вне работы по найму. Рассматривали ли Вы возможность трудоустройства сейчас на позицию уже консультанта в компанию, где ML экспертиза развита?
Спасибо, очень интересная статья!
У меня вопрос, разве не является желание, возникающее буквально с первого курса вуза, а то и раньше, открыть свой стартап и не работать на кого-то, социальным стандартом, особенно, у айтишников?
Александр, скорее, воспользовался правилом «борись с системой — не борись с системой,» и стал соответствовать социальным ожиданиям. Он работает в компании из 30 человек, большая часть которых не постоянные сотрудники, а контракторы, — стартап?
Интересно было бы задать герою статьи вопрос, как он считает, что потерял, не пойдя работать, например, в крупную аутсорсинговую компанию, где такие высококвалифицированные специалисты, как PhD по медицине, работают постоянными сотрудниками.
Отличная статья, но, возможно, лучше избегать оборота
ручной тестировщик
. Тестировщик же должен быть очень нелояльным к багам, дико нелояльным. :)
Как по мне, статья мотивирует не забывать о RCA, это уже неплохо. )
Спасибо, интересная статья.
Методология не спасёт ваш проект сама по себе, потому что смысл их изобретения, изучения, использования и комбинирования в достижении определенных целей, в том числе, проектных целей, но чаще важнее — целей компании, целей клиента, целей команды, ну и Ваших личных профессиональных целей.
Знание и опыт применения методологий даёт представление, как этих целей можно достичь не тратя лишних ресурсов, как эффективнее превышать ожидания при различной степени неопределенности требований, например.
Спасибо, интересная статья.
Достаточно полный список для испыталки для проджект менеджера, правильно расставлены акценты.
Для чего нужен испытательный
— Понять, насколько хорошо специалист справляется с задачами.
— Понять, насколько специалист соответствует культуре команды.
— Понять, насколько кандидат «нравится».
Для проджект менеджеров присоединение к уже сформированной корпоративной культуре происходит сложнее, чем для технических специалистов по различный причинам. Хороший и надежный вариант — ростить прождект менеджеров в своей культуре. О том, что для своего менеджера само собой разумеещееся, новый — может и не догадываться. Профессия такая, мы ее сами выбираем. Если что-то пошло не так и одни двери закрываются, другие открываются.
Да, статья именно об этом, об ошибках в коммуникации внутри команды.
Возможно, просто не объяснил, зачем.
Мне кажется тебе больше не нравится понятие «здравый смысл,» так как его невозможно измерить. Практически, здравый смысл и помогает достичь smart цели, иначе он не такой уж и здравый, будут перекосы как в статье.
Я говорил о помощи здравого смысла в определении необходимой меры каждого из описанных элементов, а не в выборе цели. Определение целей — это совсем другой обширный вопрос.
Да, согласен, такая модель работает. И возвращаясь к тому вопросу — как определить что проблема реально существует, если А и Б, ожидаемый и полученный результат, неизвестны? Тогда никак?
Проактивный векторный подход может быть альтернативой этому никак.