Комментарии 5
Спасибо, капитан очевидность
Тоже замечаю это за собой!
Блин, читая такое, я понимаю как наверное хорошо было в дестве. Ты что-то узнал, и тебе казалось что ты уже знаешь все :)
Обнаружились технические ограничения, которые мы не могли обойти: чтобы «подтянуть» подсказки, нужно было за пользователя авторизоваться в системе подсказок. Мы не могли этого сделать по соображениям безопасности данных пользователей
Я конечно не знаю, зачем вы там долбились месяц, но достаточно очевидно, что:
В вашем кейсе подсказки должны быть персонализированные, иначе ценность таких подсказок падает. Ну банально 20 лет назад это было сложно, но сейчас строить персонифицирование общение с клиентом - достаточно типовая задача, которая имеет смысл. Хотя возможно ваша организация еще в начале своего развития и до этого не дошла
К примеру, вы можете использовать гугль или другой ресурс для аутентификации на стороннем ресурсе. Интересно, как так выходит? Вроде ж нарушение защиты ваших данных, но нет :) Т.е. давно придуманы схемы авторизации за "Васю", чтобы получить доступ к ограниченному набору данныз о Васе, не ущемляя прав самого Васи
Ну и конечно эпично долюиться месяц, не поговорим нормально с владельцами той системы :)
же после мой руководитель спросил о причинах, а вторым его вопросом был: «А почему вы просто не вывели его из почтовой системы?»
Это назвывается "туннельный эффект". Вредная штука, лечение от нее приходит с опытом. Ну или просто спросить кого-то, кто не поддался паникке :) Просто полтора часа массового психоза многовато :)
Опыта с CMDB ни у кого в компании не было вообще, нужно было пройти весь путь с нуля. Как подступиться к нему — вообще неясно
Да так же как и к любому проекту. На самом деле, проект по своей сути - нечно новое и уникальное. Поэтому тут либо вы знаете как, либо вы еще не ПМ. Вот и все. Сорян за прямоту
Что до чек листа ... когда-то был период, искали себе ПМа на проект. Ну и собеседовали разных кандидатов. Как оказалось, все намного веселее. Многие проваливали первый вопрос вроде "зачем тебе на проекте тестировщик" и следующий "что нужно для начала тестирования".
Вы управляете даже не людьми, а взаимодействиями между ними. Взаимодействие - это передача "фишки". Когда вы знаете законы, когда "фишка" может быть передана и обеспечиваете все условия для этого - все крутится и идет как надо. Только связей в команде много и если ты понимаешь суть каждой из них - все легко. Если нет - да все равно, что там автоматизировано или все счастливы :)
Каждый член команды выполняет те задачи, которыми он должен заниматься. Нет ситуаций, когда все делают всё, и размыта зона ответственности
Это очень тонкий момент и его легко понять, и опровергнуть, если играть в коллективныу спортивную игру. Я, к примеру, 20+ лет в футбике, и поверьте - все сложнее :) Если конечно команду интересует командный результат
Это прям база менеджмента, сложно найти что-то более очевидно.
Лучше будет тратить больше времени на то, чтобы понимать менталитет менеджмента (любого уровня), чтобы потом минимизировать кол-во очевидных ошибок. Инструменты потом найдите.
Для того, чтобы проекты реализовывались оптимальным образом и без нарушения сроков, достаточно отдавать их под управление опытных менеджеров проекта. Если брать на себя эту роль без соответствующих академических знаний - закономерно будут возникать проблемы. Каждый должен делать свою работу, тогда и весь механизм будет исправен
Вижу цель, не иду к ней: как приводить проекты к результату