Анастасия Соболева. Трудные диалоги в жизни аналитика. Аналитик - центр коммуникации. И занимается переговорами. И есть смысл не просто защищать свою позицию, а предварительно посмотреть все поле торга. Как это делать - было показано на кейсе: была разработка, когда команда А завершила разработку, и команда Б близка к завершению, но разработка еще идет, пришла безопасность, которая требовала квалифицированную электронную подпись, сказав, что это подразумевалось в рекомендациях, надо было догадаться, поэтому делать надо бесплатно и в те же сроки. Как решить, команда будет делать?
Для каждой из команды брать доработку рискованно. При этом команда А начинает работать с заказчиком и хочет увеличивать присутствие, а команда Б - давно работает, обе заинтересованы в присутствие. Безопасность ссылается на требование регулятора, но там нет жесткой обязательности, при этом она не заинтересована в продукте - им надо подложить соломку. А заказчик требует сроки, потому что уже купил рекламу, и им не важно конкретное решение.
Дальше выписывают варианты решения и возможный workaround - может, надо на первом шаге вообще через людей работать. Ресурсы. А почти закончила разработку. А Б - могут быть часть сил. Она представляет команду Б. Предпочтительное решение и пределы торга. И просчитывает тоже самое для других участников. Понимает, что может и не угадать. Спектр для Б: от сохранения решения до полной реализации. И возможное привлечение сотрудников или бюджета. И еще привлечение безопасности -через экспертов, чтобы они пришли, помогли, им оплатили. Для А - они не будут заинтересованы в переработку, но, вероятно, дадут ресурс, если его оплатить. И получается, что команда Б, скорее, будет делать, и будет поле торга. И возможный workaround. В результате переговоров в данном случае нашли workaround, получилось убедить безопасность на сокращенное решение. Но подготовка - давала уверенность. Самое главное при такой подготовке переговоры идут более ответственно и получаются взвешенные решения.
Для каждой из команды брать доработку рискованно. При этом команда А начинает работать с заказчиком и хочет увеличивать присутствие, а команда Б - давно работает, обе заинтересованы в присутствие. Безопасность ссылается на требование регулятора, но там нет жесткой обязательности, при этом она не заинтересована в продукте - им надо подложить соломку. А заказчик требует сроки, потому что уже купил рекламу, и им не важно конкретное решение.
Дальше выписывают варианты решения и возможный workaround - может, надо на первом шаге вообще через людей работать. Ресурсы. А почти закончила разработку. А Б - могут быть часть сил. Она представляет команду Б. Предпочтительное решение и пределы торга. И просчитывает тоже самое для других участников. Понимает, что может и не угадать. Спектр для Б: от сохранения решения до полной реализации. И возможное привлечение сотрудников или бюджета. И еще привлечение безопасности -через экспертов, чтобы они пришли, помогли, им оплатили. Для А - они не будут заинтересованы в переработку, но, вероятно, дадут ресурс, если его оплатить. И получается, что команда Б, скорее, будет делать, и будет поле торга. И возможный workaround. В результате переговоров в данном случае нашли workaround, получилось убедить безопасность на сокращенное решение. Но подготовка - давала уверенность. Самое главное при такой подготовке переговоры идут более ответственно и получаются взвешенные решения.
Radik Adiulin. CustDev в B2B: краткий гайд и уроки после 100 проведенных интервью. Перед тем, как разрабатывать - делают CustDev, чтобы убеиться, что продукт будет востребован. Есть Качественные и количественные исследования, разные способы. В докладе - про CustDev интервью - но процесс custdev этим не исчерпывается. Это лишь часть фазы customer exploratory.
Задача интервью: понять как пользователи принимают решения, в области, где вы делаете продукт
* Кто наши пользователи
* Какую проблему решает наш продукт
* Как эти пользователи выбирают продукты
В чем разница b2c и b2b?
* b2b больше обосновывает через рациональные инструменты (деньги, kpi лиц, принимающих решения и т.п.), то b2c - эмоциональная история, лишь сопровождаемая рациональным.
* b2b - чаще пользуются одни, а покупают другие. Как дети родителям.
* b2c - проще разговорить, потому что говорят про себя, а не про компанию
* b2b - проще понять, компании более однообразны, чем люди
Этапы
* Гипотеза - обязательно прописать, даже если идея продукта - мутная.
* Целевая аудитория
* Скрипт - следование ему не догма, но скрипт должен быть.
* Интервью - заметки или запись с последующим прослушиванием, можно проводить вдвоем, в конце вопрос: о чем важном не спросили
* Результаты - фиксируем общую ситуацию, обычно достаточно 8-12 интервью, и но это не догма, а внутренне ощущение, что ты знаешь ответы
* Итоги и артефакты. Документируйте - гипотезу, аудиторию, скрипты, результаты, выводы - потому что вы на этом основании будете принимать решения о продукте, а на разработке будут всплывать вопросы об их основаниях.
Проблемы
* Нет респондентов: network, отдел продаж, конференции, комьюнити, соцсети (но надо прокачать сервисы), отзывы конкурентов, платные сервисы.
* Интервью идут не гладко - ответы не дают понимания ситуации. Надо проверять свою гипотезу, может неверный сегмент аудитории. Если коммуникация не идет - попросите помощи, признайтесь в волнении
* Исследование не дает инсайтов - надо проверить гипотезу, она вполне может быть неверной, надо ее менять, может быть нужен другой инструмент исследований.
Стоит это 30-40 часов, занимает от 2 недель до 2 месяцев.
Кого опрашивать в b2b, пользователя или того, кто платит? Зависит от продукта. Если бухгалтерия или CRM - то того, кто покупает, он построит специалистов, потому что их много. А вот в сегментах, где дефицит квалифицированных специалистов, которые могут уйти, если их построят - то к пользователям надо идти. Можно еще поделить сегменты, про деньги - с одним, а сейла - о том, почему он до сих пор ведет Excel, а не пользуется CRM.
Задача интервью: понять как пользователи принимают решения, в области, где вы делаете продукт
* Кто наши пользователи
* Какую проблему решает наш продукт
* Как эти пользователи выбирают продукты
В чем разница b2c и b2b?
* b2b больше обосновывает через рациональные инструменты (деньги, kpi лиц, принимающих решения и т.п.), то b2c - эмоциональная история, лишь сопровождаемая рациональным.
* b2b - чаще пользуются одни, а покупают другие. Как дети родителям.
* b2c - проще разговорить, потому что говорят про себя, а не про компанию
* b2b - проще понять, компании более однообразны, чем люди
Этапы
* Гипотеза - обязательно прописать, даже если идея продукта - мутная.
* Целевая аудитория
* Скрипт - следование ему не догма, но скрипт должен быть.
* Интервью - заметки или запись с последующим прослушиванием, можно проводить вдвоем, в конце вопрос: о чем важном не спросили
* Результаты - фиксируем общую ситуацию, обычно достаточно 8-12 интервью, и но это не догма, а внутренне ощущение, что ты знаешь ответы
* Итоги и артефакты. Документируйте - гипотезу, аудиторию, скрипты, результаты, выводы - потому что вы на этом основании будете принимать решения о продукте, а на разработке будут всплывать вопросы об их основаниях.
Проблемы
* Нет респондентов: network, отдел продаж, конференции, комьюнити, соцсети (но надо прокачать сервисы), отзывы конкурентов, платные сервисы.
* Интервью идут не гладко - ответы не дают понимания ситуации. Надо проверять свою гипотезу, может неверный сегмент аудитории. Если коммуникация не идет - попросите помощи, признайтесь в волнении
* Исследование не дает инсайтов - надо проверить гипотезу, она вполне может быть неверной, надо ее менять, может быть нужен другой инструмент исследований.
Стоит это 30-40 часов, занимает от 2 недель до 2 месяцев.
Кого опрашивать в b2b, пользователя или того, кто платит? Зависит от продукта. Если бухгалтерия или CRM - то того, кто покупает, он построит специалистов, потому что их много. А вот в сегментах, где дефицит квалифицированных специалистов, которые могут уйти, если их построят - то к пользователям надо идти. Можно еще поделить сегменты, про деньги - с одним, а сейла - о том, почему он до сих пор ведет Excel, а не пользуется CRM.
Екатерина Лысенко. Сколько благородства в рисках? Прекрасный доклад о том, как заниматься рисками. Под "заниматься" в докладе имеется ввиду порождение списков потенциальных событий, которые влияют на проект и обсуждение нашей готовности их пережить, включая принятие риска: "будут бить - будем отбиваться". Есть еще варианты работы с рисками, я о них напишу в конце, а пока - конспект доклада.
Фразы "риск - дело благородное", "кто не рискует - не пьет шампанское" Екатерину всегда смущали. В рисками надо работать, и эта работа очень близка работе с багами, которые тоже случаются. Баг - частный случай риска.
Риск не всегда несет угрозу, как и стресс. Есть дистресс: все плохо и мы все умрем, и эустресс: все плохо, но мы всех победим. Так и события - одни несут угрозу, а другие - открывают возможность, и надо быть готовым ее подхватить. Цель управления рисками - за все хорошее и против всего плохого.
Что достигается путем работы с рисками?
* Возможность более точного определения срока и границ проекта. Это не про курсы, где учат "что будет, когда сломает ногу", "что будет, если не хватит финансирование" - не анализ не провели, или команду не набрали. Рисками занимаешься в истории от полугода (в старой реальности)
* Гибкость планирования и построения стратегии - про риски ты думаешь, и у тебя появляются сценарии. И не только на работе, но и в жизни. К сожалению или к радости - непонятно, иногда это как паранойя, а иногда выручает.
* Повышение прозрачности на уровне компании
* Сокращение числа инцидентов - вы об этом подумали
* Качество взаимодействия
* Качество взаимодействия между бизнес-подразделениями и разработкой - увеличивается понимание
* Формирование ценностного подхода на корпоративном уровне
Комикс из Дилберта, по-моему. Я оценил шансы что все пройдет гладко 70%. То есть когда провалится - ты признаешь, что был неправ? Но я только оценил шансы... Если у руководства такое отношение, то работать с рисками бесполезно. Риск менеджмент - это не игра в одни ворота. Риск - у компании, любой риск - твой риск. Нельзя заниматься в позиции эксперта. Риски приводят нас к необходимости анализировать, а это - ретроспективные практики. Самокопание, умение признавать собственные ошибки и далее - права на ошибку.
Типизация рисков. В разных книгах - по-разному, до 12. У нее - 4.
* Нормативно-правовые: законодательство и т.п.
* Ресурсные Прибыль, время, люди, техника. Риски по технике сейчас увеличились, на Кипре месяц нет поставки клавиатур с русскими буквами, с поставкой серверов, ноутбуков.
* Репутационные. По потребителям, пользователям, контрагентам, сообществам. И может быть положительный риск, представьте вы рассказываете о классной трансформации регламента или условиях работы - и репутацию запоминают. Социально-значимый контекст. Шаттлы, трагедия Челленджера - через два часа Рейган выступил с обращением к нации, и впервые начал "Нэнси и я" - семейная тема, и он нивелировал значительную часть рисков. Несоответствие качеству
* Технические риски: интеграционные, инфраструктурные и архитектурные. Внезапно узнаешь, что железка не отдает количество залитого топлива, а true/false.
Выявляют через анкетирование, мозговой штурм, изучение процессов и документации, анализ данных. Очень важно, чтобы на мозговых штурмах были представители всех бизнес-подразделений, нельзя качественно играть за другого. Как написано в коде - точно так и работает. И дальше посмотреть разницу между тем, что думает бизнес, и что есть на самом деле. Анализ данных - не средние, а особые случаи, которые выбиваются - вам важно понять что было там, и может ли это повториться.
Как работать с рисками? ROAMboard. Табличка, двигаем по доске: Resolved - Owned (есть владелец) - Accepted (принят участниками) - Mitigated (последствия минимизированы). Что классно? В работе с доской вы приучаете компанию к тому, что вы открыто обсуждаете риски и проблемы, что они должны быть видны всем. И вы начинаете разделять (share) ответственность. Есть антифрод или безопасность, вы показываете, за что они отвечают.
Фразы "риск - дело благородное", "кто не рискует - не пьет шампанское" Екатерину всегда смущали. В рисками надо работать, и эта работа очень близка работе с багами, которые тоже случаются. Баг - частный случай риска.
Риск не всегда несет угрозу, как и стресс. Есть дистресс: все плохо и мы все умрем, и эустресс: все плохо, но мы всех победим. Так и события - одни несут угрозу, а другие - открывают возможность, и надо быть готовым ее подхватить. Цель управления рисками - за все хорошее и против всего плохого.
Что достигается путем работы с рисками?
* Возможность более точного определения срока и границ проекта. Это не про курсы, где учат "что будет, когда сломает ногу", "что будет, если не хватит финансирование" - не анализ не провели, или команду не набрали. Рисками занимаешься в истории от полугода (в старой реальности)
* Гибкость планирования и построения стратегии - про риски ты думаешь, и у тебя появляются сценарии. И не только на работе, но и в жизни. К сожалению или к радости - непонятно, иногда это как паранойя, а иногда выручает.
* Повышение прозрачности на уровне компании
* Сокращение числа инцидентов - вы об этом подумали
* Качество взаимодействия
* Качество взаимодействия между бизнес-подразделениями и разработкой - увеличивается понимание
* Формирование ценностного подхода на корпоративном уровне
Комикс из Дилберта, по-моему. Я оценил шансы что все пройдет гладко 70%. То есть когда провалится - ты признаешь, что был неправ? Но я только оценил шансы... Если у руководства такое отношение, то работать с рисками бесполезно. Риск менеджмент - это не игра в одни ворота. Риск - у компании, любой риск - твой риск. Нельзя заниматься в позиции эксперта. Риски приводят нас к необходимости анализировать, а это - ретроспективные практики. Самокопание, умение признавать собственные ошибки и далее - права на ошибку.
Типизация рисков. В разных книгах - по-разному, до 12. У нее - 4.
* Нормативно-правовые: законодательство и т.п.
* Ресурсные Прибыль, время, люди, техника. Риски по технике сейчас увеличились, на Кипре месяц нет поставки клавиатур с русскими буквами, с поставкой серверов, ноутбуков.
* Репутационные. По потребителям, пользователям, контрагентам, сообществам. И может быть положительный риск, представьте вы рассказываете о классной трансформации регламента или условиях работы - и репутацию запоминают. Социально-значимый контекст. Шаттлы, трагедия Челленджера - через два часа Рейган выступил с обращением к нации, и впервые начал "Нэнси и я" - семейная тема, и он нивелировал значительную часть рисков. Несоответствие качеству
* Технические риски: интеграционные, инфраструктурные и архитектурные. Внезапно узнаешь, что железка не отдает количество залитого топлива, а true/false.
Выявляют через анкетирование, мозговой штурм, изучение процессов и документации, анализ данных. Очень важно, чтобы на мозговых штурмах были представители всех бизнес-подразделений, нельзя качественно играть за другого. Как написано в коде - точно так и работает. И дальше посмотреть разницу между тем, что думает бизнес, и что есть на самом деле. Анализ данных - не средние, а особые случаи, которые выбиваются - вам важно понять что было там, и может ли это повториться.
Как работать с рисками? ROAMboard. Табличка, двигаем по доске: Resolved - Owned (есть владелец) - Accepted (принят участниками) - Mitigated (последствия минимизированы). Что классно? В работе с доской вы приучаете компанию к тому, что вы открыто обсуждаете риски и проблемы, что они должны быть видны всем. И вы начинаете разделять (share) ответственность. Есть антифрод или безопасность, вы показываете, за что они отвечают.
Цикл работы с рисками: Периодическая оценка - Выявление риска - Анализ риска - Оценка риска - Принятие решения.
Разработка продукта - не столько риск задержки разработки, сколько риск не выдержать успех, когда пользователи вдруг массово пришли. Риски могут принимать разные. Астронавт не вернется - принимает он, принимает пиар-служба (а если случится - что делаем) и так далее. Дальше был пример - риск не-выпекания колобка.
Есть риски, которые нивелировать дороже, чем принять. Все люди болеют - решим в моменте, нет скамейки запасных.
Атрибуты риска. Не только содержание риска, но название, последствия реализации риска. У одного риска могут быть разные причины - можно раздавать ответственности. Критичность.
Психология. Когда у тебя много проблем в стрессе, ты все равно берешь проблемы. Помогаешь другим, сообществу - чтобы получить подтверждение. А реально начинаешь тонуть.
Про критичность - почитать японские книги про минимализм. Там лучше всего написано. Есть проблема - обведите кружочком, сделайте шаблон, действуйте по шаблону, стало неудобно - поменяйте шаблон.
Обоснование в цифрах. Поддержка говорит "умираем". А выясняется, что два студента пару часов в неделю разбирают - а исправление пара недель рефакторинга команды - и пусть студенты разбирают. С нормативно-правовыми тоже самое, последствия разные: если отнимут лицензию - надо чинить, а если небольшой штраф - можно заплатить.
Триггер. Ситуация, которая должна наступить, чтобы риски сработали. Не обязательно катастрофа. Триггер обычно тоже риск. Можно в ROAM board - связи между рисками. В некоторый момент перейдете от ROAM board к mindmap. Это - следующий этап.
А теперь - мои дополнения. Во-первых, помимо такой простой работы может быть сценарное планирование: если данное событие произойдет, то мы сделаем это и это (План-Б), при этом, чтобы во-время среагировать, будем следить за этим и этим. Например, так работают с рисками стартапов венчурные компании: чтобы не влипнуть с инвестициями, при не достижении таких-то результатов в такие-то сроки и деньги (веха) мы закрываем проект, а команду будем пристраивать таким-то образом (чтобы у людей не было страха за судьбу). А во-вторых во многих корпорациях целью работы с рисками является на задача выполнить проект, как у Екатерины, а задача избежать наказания менеджеров за провал проекта, и это - совсем другая работа с рисками.
Разработка продукта - не столько риск задержки разработки, сколько риск не выдержать успех, когда пользователи вдруг массово пришли. Риски могут принимать разные. Астронавт не вернется - принимает он, принимает пиар-служба (а если случится - что делаем) и так далее. Дальше был пример - риск не-выпекания колобка.
Есть риски, которые нивелировать дороже, чем принять. Все люди болеют - решим в моменте, нет скамейки запасных.
Атрибуты риска. Не только содержание риска, но название, последствия реализации риска. У одного риска могут быть разные причины - можно раздавать ответственности. Критичность.
Психология. Когда у тебя много проблем в стрессе, ты все равно берешь проблемы. Помогаешь другим, сообществу - чтобы получить подтверждение. А реально начинаешь тонуть.
Про критичность - почитать японские книги про минимализм. Там лучше всего написано. Есть проблема - обведите кружочком, сделайте шаблон, действуйте по шаблону, стало неудобно - поменяйте шаблон.
Обоснование в цифрах. Поддержка говорит "умираем". А выясняется, что два студента пару часов в неделю разбирают - а исправление пара недель рефакторинга команды - и пусть студенты разбирают. С нормативно-правовыми тоже самое, последствия разные: если отнимут лицензию - надо чинить, а если небольшой штраф - можно заплатить.
Триггер. Ситуация, которая должна наступить, чтобы риски сработали. Не обязательно катастрофа. Триггер обычно тоже риск. Можно в ROAM board - связи между рисками. В некоторый момент перейдете от ROAM board к mindmap. Это - следующий этап.
А теперь - мои дополнения. Во-первых, помимо такой простой работы может быть сценарное планирование: если данное событие произойдет, то мы сделаем это и это (План-Б), при этом, чтобы во-время среагировать, будем следить за этим и этим. Например, так работают с рисками стартапов венчурные компании: чтобы не влипнуть с инвестициями, при не достижении таких-то результатов в такие-то сроки и деньги (веха) мы закрываем проект, а команду будем пристраивать таким-то образом (чтобы у людей не было страха за судьбу). А во-вторых во многих корпорациях целью работы с рисками является на задача выполнить проект, как у Екатерины, а задача избежать наказания менеджеров за провал проекта, и это - совсем другая работа с рисками.
👍2
Полторы недели назад был в Ереване на SQAdays и AnalystDays. Влад Орликов сделал площадку общения между ИТ-шниками, которые оказались в разных странах ввиду современной геополитики, на конференции было много международных спикеров. Я хочу отметить не только активное общение, но и спокойную, ламповую обстановку и общий позитив. Публикую отчет https://mtsepkov.org/SQA-Analyst-EA2022 - собрал в него заметки с докладов и добавил общие впечатления.
👍10
Первый доклад ArchDays. Сергей Харламов. Архитектура масштабирования: ускоряем обработку и повышаем доступность данных. В современных распределенных системах транзакционность ACID на уровне системы, а не отдельной ноды или процесса практически не поддерживается, фокус на высокой доступности на смену ACID пришел BASE: Base Availability при сбоях, Soft state вместо acid-консистентности, Eventual consistency согласованность в будущем. При этом такие решения часто реализуются поверх старого РДБМСб которое используется как базовое хранилище в legacy- системах, от которых не отказываются. Для достижения используются различные механизмы: репликация баз данных; разные виды кеширования, при которых кэш работает как промежуточная БД, организованная по-другому, чем исходная; стриминг CQRS; CDC (Change Data Capture). Эти механизмы могут быть доступны в виде готовых решений, для других в БД предусмотрены точки расширения, третьи реализуются на уровне кода приложения. Засада в том, что в этих механизмах нужно разбираться для разбора инцидентов пользователей, и так же для понимания рисков при падении и последующем восстановлении. Это - не внутренность разработки, которая была В докладе был обзор шаблонов и разбор плюсов и побочных эффектов. Но рассказывать текстом - бесполезно, надо смотреть схемы на слайдах, так что смотрите презентацию.
👍2
Максим Юнусов. Изобретение архитектурного решения. Начат с классической ситуации: получив требования по времени отклика под нагрузкой и доступность сервиса с намеком, что для этого сервис должен масштабироваться, Архитектор выдает решение: PostgreSQL + хореография на событиях + Apache Kafka. Вопрос: как решение связано с исходными требованиями? И дальше был разбор предлагаемого порождения решений. Для начала посмотрим, что предлагают методологии: TOGAF, SEI, ADR. Интересно, что они все исходят из того, что должны быть стандартные решения, и задача выбора состоит лишь во взвешивании вариантов. Различается косметика, подходы к принятию и документированию этих решений. И это - печально. Поэтому предлагается посмотреть на смежные области, а именно на ТРИЗ. Там много интересного и полезного.
* Исходное описание - лишь описание ситуации, в ней пока не выявлено противоречие. Необходимо до этого довести, получить задачу.
* Противоречия бывают двух видов: противоречат два нефункциональных требования или нефункциональное требование противоречит архитектурному принципу.
* Для нефункциональных требований нужна заинтересованная сторона - кто заинтересован в его исполнении.
* Нефункциональное требование стоит подвергать сомнению. Действительно ли доступность сайта ниже 99.99 или время отклика более 0.1c приведет к оттоку пользователей (если это указали как основание требования). Может быть, требование можно ослабить или вообще снять?
* Решать противоречия следует, только если требования реально актуальны. Иначе будет overdesign, необоснованно сложное решение.
* Архитектурные принципы и ограничения тоже стоит подвергать сомнению.
* Антипаттерн, если в задаче не должно быть заложен подход к решению, когда сразу говорят, что из требований следует необходимость масштабировать сервиса на кластер
* Антипаттерн, если свобода сведена к свободе выбора из известного. А именно это предлагают методологии.
Разрешение противоречия
* Идеальное решение без ограничений
* Вводим ограничения до потери качества
* Формулируем физическое противоречие
Пример: архив должен создаваться для обеспечения надежности и НЕ должен создаваться, так как деградирует время отклика. Решаем
* во времени: делаем архив, когда низкая нагрузка
* в пространстве: делаем с отдельной ноды БД, которая для этого
* в структуре: две базы данных: для записи и для архива
* взаимодействия: приостанавливаем процесс архивирования при интенсивных запросах
* Архив как идеальный объект, архивирование без архива. Например, если архив нужен для отката - делаем откат иным образом, откручивая обработку событий назад.
* Исходное описание - лишь описание ситуации, в ней пока не выявлено противоречие. Необходимо до этого довести, получить задачу.
* Противоречия бывают двух видов: противоречат два нефункциональных требования или нефункциональное требование противоречит архитектурному принципу.
* Для нефункциональных требований нужна заинтересованная сторона - кто заинтересован в его исполнении.
* Нефункциональное требование стоит подвергать сомнению. Действительно ли доступность сайта ниже 99.99 или время отклика более 0.1c приведет к оттоку пользователей (если это указали как основание требования). Может быть, требование можно ослабить или вообще снять?
* Решать противоречия следует, только если требования реально актуальны. Иначе будет overdesign, необоснованно сложное решение.
* Архитектурные принципы и ограничения тоже стоит подвергать сомнению.
* Антипаттерн, если в задаче не должно быть заложен подход к решению, когда сразу говорят, что из требований следует необходимость масштабировать сервиса на кластер
* Антипаттерн, если свобода сведена к свободе выбора из известного. А именно это предлагают методологии.
Разрешение противоречия
* Идеальное решение без ограничений
* Вводим ограничения до потери качества
* Формулируем физическое противоречие
Пример: архив должен создаваться для обеспечения надежности и НЕ должен создаваться, так как деградирует время отклика. Решаем
* во времени: делаем архив, когда низкая нагрузка
* в пространстве: делаем с отдельной ноды БД, которая для этого
* в структуре: две базы данных: для записи и для архива
* взаимодействия: приостанавливаем процесс архивирования при интенсивных запросах
* Архив как идеальный объект, архивирование без архива. Например, если архив нужен для отката - делаем откат иным образом, откручивая обработку событий назад.
👍4
Евгений Лукьянов. Как Event Storming, DDD и чистая архитектура помогают запустить стартап. Реально история стартапа в области здоровья, в котором много алгоритмики и ML. На первом шаге была проверка алгоритмов, потом - проверка концепции на знакомых с интерфейсом на чат-боте. При этом разработку вел один человек на python, и получился сложный, взаимно-перевязанный код из множества сервисов, который очень сложно дальше дорабатывать. В некоторый момент потребовалось научиться вести разработку командой, а для этого потребовалось разобраться и упростить то, что сделано, обеспечить возможность подключения новичков. А потом был следующий этап - проверка спроса на сервис с партнерами, и там был следующий такт изменений.
На первом этапе
* Event Storming, чтобы разобраться, что делает приложение. Он показал, что основной разработчик не слишком представляет.
* Шаг к гексагональной архитектуре
* Внедрили тактические паттерны DDD: сбор бизнес-логики в агрегаты, Value-object, большие сервисы разбили на UseCase.
* Сделали референсный проект для погружения новичков.
На втором этапе
* Научили аналитиков пользоваться Event storming. Получились ограниченные контексты, области поделились. И в контекстах можно менять технологии.
* Нарисовали интерфейсы, отдали партнерам на тестирование.
* Типизация стандартных решений позволила включать новичков на локальные задачи. У новичка на следующий день есть сделанная простая задача. Разделение по квалификации.
* Прогнозирование. Сложный агрегат - 2 недели, простой два дня, объект-значение 6 часов, usecase 3 часа. За счет типизации решений.
* Trunk Based Development. Без веток. Потому что решение конфликтов было дорогим. Но Trunk based - невозможен без автоматики и хорошего тестирования.
* Тесты - есть заранее подготовленные данные окружения для запуска теста.
* Локальная сборка экономит деньги. Build-server - предохранитель.
* TDD для сложных мест
* Начали допускать тех.долг на этапах апробации решений
* Ограничили свободу - типовые узлы уже изготовлены, используешь их.
Книга: Accelerate: The Science of Lean Software Development and DevOps. Jez Humble, Gene Kim, Nicole Forsgren.
На первом этапе
* Event Storming, чтобы разобраться, что делает приложение. Он показал, что основной разработчик не слишком представляет.
* Шаг к гексагональной архитектуре
* Внедрили тактические паттерны DDD: сбор бизнес-логики в агрегаты, Value-object, большие сервисы разбили на UseCase.
* Сделали референсный проект для погружения новичков.
На втором этапе
* Научили аналитиков пользоваться Event storming. Получились ограниченные контексты, области поделились. И в контекстах можно менять технологии.
* Нарисовали интерфейсы, отдали партнерам на тестирование.
* Типизация стандартных решений позволила включать новичков на локальные задачи. У новичка на следующий день есть сделанная простая задача. Разделение по квалификации.
* Прогнозирование. Сложный агрегат - 2 недели, простой два дня, объект-значение 6 часов, usecase 3 часа. За счет типизации решений.
* Trunk Based Development. Без веток. Потому что решение конфликтов было дорогим. Но Trunk based - невозможен без автоматики и хорошего тестирования.
* Тесты - есть заранее подготовленные данные окружения для запуска теста.
* Локальная сборка экономит деньги. Build-server - предохранитель.
* TDD для сложных мест
* Начали допускать тех.долг на этапах апробации решений
* Ограничили свободу - типовые узлы уже изготовлены, используешь их.
Книга: Accelerate: The Science of Lean Software Development and DevOps. Jez Humble, Gene Kim, Nicole Forsgren.
👍1
Геннадий Круглов. SAGA — эволюция и новые смыслы. Сообщество архитекторов решило разобраться, что же такое SAGA, и в докладе представлен результат этого. К сожалению, не впечатляющий. Начали от базовых понятий, подняли статьи 1980-х о том, что же такое - транзакции, какие у них свойства (ACID) и какие проблемы. Одна из них - long life transaction при распределенных системах, которые при формальной реализации ведут к эскалации блокировок. И потому предложено делать промежуточный коммиты внутри транзакции, разбивая их на малые участки, после которых бизнес-консистентности нет, а SAGA - концептуальный способ восстановления этой консистентности, тоже предложенный давно, в 1986. За счет того, что есть управляющая часть, которая в случае прерывания в неконсистентном состоянии либо откатывает шаги, для чего должны быть предусмотрены средства отката, либо проталкивает до завершения, если для этого есть средства. Собственно, все. Как это реализуется - было за пределами доклада, хотя были ссылки на статьи Microsoft, Red Hat, AWS, Camunda. В общем, жаль, что содержание ограничилось этим. Я тут хочу отметить, что в сентябре был доклад Филиппа Дельгадо "Микросервисы через боль и превозмогание" на Saint Highload (кому интересно - мой конспект), где в числе прочего он говорил про SAGA, пунктиром обозначив минимум четыре шаблона реализации. И я надеялся услышать про шаблоны и концепты более детально, а получилась лишь историческая справка про статьи 1980-х о транзакциях и SAGA.
Дмитрий Таболич. Майндшифт или мысли, как Архитектор. Очень крутой доклад про отличие мышления архитектора от мышления инженера-разработчика. Это первый сдвиг мышления, касающийся именно технологического стека. Дальше добавляются другие аспекты: business focus, governance, strategy, но начало - именно в сдвиге мышления по техническим вопросам. Если кратко, то для каждой задачи архитектор смотрит спектр вариантов решений и ответственно делает выбор с учетом контекста конкретного проекта. Это достаточно абстрактно, поэтому в докладе это иллюстрировано большим количеством кейсов.
* Есть задача от проджекта. Инженер: давайте сделаем. Архитектор: какие ограничения?
* Silver bullet. Инженер: я много раз делал, и сделаю еще раз на своем опыте. Архитектор: для начала смотрим альтернативы индустрии, потом - выбираем. Если решение одно - значит нет ни одного.
* Документируй. Инженер: хороший код self-explained. Архитектор: очевидно, необходимо описывать ключевые решения, вопрос не стоит. И надо быть готовым
* Task-driven mindset. Инженеру важна четкая постановка задачи - что сделать. Для архитектора - зачем делаем, какую проблему решаем
* CV-driven mindset. Инженер: давайте втащим фреймворк. Архитектор: многофакторная оценка уместности - безопасность, скиллы команды и т.п. Вопрос не торможения, а именно многоаспектной оценки.
* Язык бэкенда и фронтенда. Инженер - только на техническом языке структуры приложения. Архитектор - много viewpoint, в том числе - на языке бизнес-стейкхолдеров, на языке безопасников и так далее.
* Копипаст. Инженер: посмотрим на stackoverflow и заберем готовый кусок не разбираясь. Архитектор: решения надо смотреть, но надо смотреть несколько и анализировать уместность, делая выбор.
* Призма мышления. Инженер: сужаем область понимания на задачу. Архитектор: включение задачи в большую систему и влияние на нее.
* Роль или функция? Инженер: играл роль архитектора в своей команде - значит архитектор. Архитектор: может играть эту роль НЕ ТОЛЬКО в своем проекте, где есть многолетний опыт, может быстро разбираться в других проектах.
* Я-эксперт. Инженер: отслеживаешь развитие своей платформы, своих технологий. Архитектор - смотришь на множество технологий, на варианты построения решений.
* HERO. Инженер: выбрана технология, и дальше много усилий, чтобы заставить работать, даже если она не подходит. Например, сначала выбрать JVM для serverless и бороться с долгим стартом JVM. Архитектор: оценивает решения в контексте проекта.
* Тот самый YAGNI. Мы решили выбрать Mongo, потому что там - транзакции, хотя они и не нужны. Архитектор - обоснованные решения в контексте конкретного проекта, а не вообще
* IT works on my machine: Инженер: у меня все работает. Архитектор - что DevOps процесс позволяет
* Все по Scrum. Инженер: о следующей функциональности посмотрим в следующем спринте. Архитектор: видим контекст вперед, не привязываем решения к моменту.
* Ответственность. Инженер: склонен передать ответственность на коллективное принятие решений. Архитектор - не просто принимает решения, но и несет ответственность за принятые решения.
И с заключении книги:
* 97 Things Every Software Architect Should Know и
* BTABoЛ 3.0: Business Technology Architecture Body of Knowledge
* Есть задача от проджекта. Инженер: давайте сделаем. Архитектор: какие ограничения?
* Silver bullet. Инженер: я много раз делал, и сделаю еще раз на своем опыте. Архитектор: для начала смотрим альтернативы индустрии, потом - выбираем. Если решение одно - значит нет ни одного.
* Документируй. Инженер: хороший код self-explained. Архитектор: очевидно, необходимо описывать ключевые решения, вопрос не стоит. И надо быть готовым
* Task-driven mindset. Инженеру важна четкая постановка задачи - что сделать. Для архитектора - зачем делаем, какую проблему решаем
* CV-driven mindset. Инженер: давайте втащим фреймворк. Архитектор: многофакторная оценка уместности - безопасность, скиллы команды и т.п. Вопрос не торможения, а именно многоаспектной оценки.
* Язык бэкенда и фронтенда. Инженер - только на техническом языке структуры приложения. Архитектор - много viewpoint, в том числе - на языке бизнес-стейкхолдеров, на языке безопасников и так далее.
* Копипаст. Инженер: посмотрим на stackoverflow и заберем готовый кусок не разбираясь. Архитектор: решения надо смотреть, но надо смотреть несколько и анализировать уместность, делая выбор.
* Призма мышления. Инженер: сужаем область понимания на задачу. Архитектор: включение задачи в большую систему и влияние на нее.
* Роль или функция? Инженер: играл роль архитектора в своей команде - значит архитектор. Архитектор: может играть эту роль НЕ ТОЛЬКО в своем проекте, где есть многолетний опыт, может быстро разбираться в других проектах.
* Я-эксперт. Инженер: отслеживаешь развитие своей платформы, своих технологий. Архитектор - смотришь на множество технологий, на варианты построения решений.
* HERO. Инженер: выбрана технология, и дальше много усилий, чтобы заставить работать, даже если она не подходит. Например, сначала выбрать JVM для serverless и бороться с долгим стартом JVM. Архитектор: оценивает решения в контексте проекта.
* Тот самый YAGNI. Мы решили выбрать Mongo, потому что там - транзакции, хотя они и не нужны. Архитектор - обоснованные решения в контексте конкретного проекта, а не вообще
* IT works on my machine: Инженер: у меня все работает. Архитектор - что DevOps процесс позволяет
* Все по Scrum. Инженер: о следующей функциональности посмотрим в следующем спринте. Архитектор: видим контекст вперед, не привязываем решения к моменту.
* Ответственность. Инженер: склонен передать ответственность на коллективное принятие решений. Архитектор - не просто принимает решения, но и несет ответственность за принятые решения.
И с заключении книги:
* 97 Things Every Software Architect Should Know и
* BTABoЛ 3.0: Business Technology Architecture Body of Knowledge
🔥4
Денис Котов из Tinkoff. BPM(N,S, engine) — нужны или нет? Интересный доклад о месте BPM-схем и движков, которые их реализуют. Тезис состоит в том, что если у вас есть хороший BPM-движок, то вы из коробки имеет мощное средство реализации процессов, которое берет на себя не только задачу выполнения экземпляра процесса для конкретной ситуации, но так же отработку особых ситуаций, перезапуск или откат процесса, миграцию экземпляров при появлении новых версий версий описания и мониторинг. При этом у вас из коробки есть таймеры, напоминания, уведомления, механизмы прерываний по событиям и многое другое, и вам нужно лишь реализовывать конкретные шаги, которые может делать конкретная автоматизированная система или человек. Процессы, которые реализует BPMN - гораздо мощнее, чем те, которые дает State machine, процесс имеет много состояний. Это Денис показывал на примере регистрации ИП, которая начиналась с 10+ последовательных шагов, которые действительно просто реализовать на Sate machine, и за полтора года развития превратилась в сложную схему, в которой около 11 переменных-состояний.
Вопрос в том, где взять этот хороший BPMN-движок, который все это дает из коробки. Начинали они с использования IBM process designer, который всем хорош, только безнадежно отстал по технологиям: Java 6 и никакой интеграции с современными CI/CD и системами тестирования. Потом делали свою State machine, это жило, но с ростом числа процессов, команды и без визуализации и многих других поддерживающих сервисов было сложно. Cейчас - Kotlin как язык, Camunda как движок, spring для обвязки и Kafka для интеграций. Плюс свое решение на Prometheus и Grafana для мониторинга.
Есть нюанс про уместность использования. Маркетологи успешно продают BPM-решения как серебряную пулю для всего. А сейчас еще идет аккуратное брендирование этих движков под LowCode, когда люди смогут тыкать мышкой без программистов. Это все - маркетинг. Уместно применение для реально сложных процессов, где много взаимодействия людей и систем, и которые разворачиваются во времени. И с низкой нагрузкой, 10+ инстансов ежедневно. Хотя camunda 8 обещает масштабировать до 100-1000+ - но тоже ежедневно.
А еще BPMN - сложен, 15 абстракций и 500 графических конструкций. Поэтому для простых задач его использовать не надо, надо использовать Workflow engine, которых много - Temporal, Cadence и так далее. Там всего пара абстракций, и гораздо меньше графических конструкций и для большого количества задач этого достаточно.
Вопрос в том, где взять этот хороший BPMN-движок, который все это дает из коробки. Начинали они с использования IBM process designer, который всем хорош, только безнадежно отстал по технологиям: Java 6 и никакой интеграции с современными CI/CD и системами тестирования. Потом делали свою State machine, это жило, но с ростом числа процессов, команды и без визуализации и многих других поддерживающих сервисов было сложно. Cейчас - Kotlin как язык, Camunda как движок, spring для обвязки и Kafka для интеграций. Плюс свое решение на Prometheus и Grafana для мониторинга.
Есть нюанс про уместность использования. Маркетологи успешно продают BPM-решения как серебряную пулю для всего. А сейчас еще идет аккуратное брендирование этих движков под LowCode, когда люди смогут тыкать мышкой без программистов. Это все - маркетинг. Уместно применение для реально сложных процессов, где много взаимодействия людей и систем, и которые разворачиваются во времени. И с низкой нагрузкой, 10+ инстансов ежедневно. Хотя camunda 8 обещает масштабировать до 100-1000+ - но тоже ежедневно.
А еще BPMN - сложен, 15 абстракций и 500 графических конструкций. Поэтому для простых задач его использовать не надо, надо использовать Workflow engine, которых много - Temporal, Cadence и так далее. Там всего пара абстракций, и гораздо меньше графических конструкций и для большого количества задач этого достаточно.
👍13❤1🤔1
Собрал свои заметки с ArchDays в отчет https://mtsepkov.org/ArchDays-2022 Отмечу, что конференция имеет свое лицо и отчетливый фокус на архитектуре и работе архитектора. Доклады по этой теме есть на Highload, но там больше фокуса на public web и высоконагруженные приложения, а на ArchDays речь идет больше про enterprise и связанные с этим темы, которые на Highload не слишком широко представлены. При этом в докладах на ArchDays больше фокус на объяснении базовых вещей. Для кого-то этот материал очевиден, а для других - является ценным. А еще было несколько докладов, посвященных мышлению архитектора и способам принятия архитектурных решений, и это, на мой взгляд, очень позитивно отличает конференцию в хорошую сторону.
❤5🔥2
Начинаю репортаж с #AnalystDays. Николай Соколовский. Модели решений и фреймворк: фиксируем сложную бизнес-логику. Рассказ про способ формальной записи развивающихся и усложняющихся правил. Которые начинаются с простой формулировки "Заявка может быть закрыта автором или исполнителем", а дальше добавляются новые роли, статусы (Отклонена), особые заявки, отметки на заявке и так далее, и текстовые формулировки становятся запутанными, а на трактовку влияют знаки препинания, что ведет к ошибкам. Это Decision Making Notation записи в виде табличек условий и заключений, столбцы условия объединяются по И, строки - по ИЛИ. Есть две визуализации, одна из 4 элементов: Входные данные, Решение, Бизнес-знания, Источник знаний, во второй погружаешься внутрь: Правила декомпозируются через Условия, они объединены в Семейства и Модели. Но основное - таблички, и фишка в том что бизнес такие таблички понимает и готов обсуждать и заполнять после 10 минут инструктажа. А по реализации - есть много движков, и можно написать свой, интерпретация довольно простая.
С табличками можно формально работать - проверять, выносить условия, декомпозировать, например, выделив правило будний/выходной, которое встречается во многих местах логики, в отдельные правила. Понятно, что тут все как с выделением общих процедур, когда появляется зверек "нерабочий день", который где-то трактуется как будний, где-то как выходной, а где-то порождает новую ветку - то придется надо разбираться. Но ты, как минимум, явно видишь исчерпывающий список таких мест. В докладе было много примеров по использованию в разных ситуациях, не только в бизнес-логике, но и в DWH и BI.
Достоинства - позволяют управлять большими наборами правил, 500+ выживают, можно увидеть зависимости, облегчают декомпозицию и управление. Сочетаются с BPMN. Автоматизация. Малый порог входа, бизнес понимает, включая финансистов и HR. Недостатки тоже понятны: еще одна нотация, слишком сложно для простых случаев. Требует аккуратного обращения с терминологией. Сложно описывать случаи, которых не было, но тут помогает сказать "ну, а пусть ошиблись - что система должна делать". Сложно согласовывать, когда декомпозиция не совпадает с границами ответственности - учитывайте их.
С табличками можно формально работать - проверять, выносить условия, декомпозировать, например, выделив правило будний/выходной, которое встречается во многих местах логики, в отдельные правила. Понятно, что тут все как с выделением общих процедур, когда появляется зверек "нерабочий день", который где-то трактуется как будний, где-то как выходной, а где-то порождает новую ветку - то придется надо разбираться. Но ты, как минимум, явно видишь исчерпывающий список таких мест. В докладе было много примеров по использованию в разных ситуациях, не только в бизнес-логике, но и в DWH и BI.
Достоинства - позволяют управлять большими наборами правил, 500+ выживают, можно увидеть зависимости, облегчают декомпозицию и управление. Сочетаются с BPMN. Автоматизация. Малый порог входа, бизнес понимает, включая финансистов и HR. Недостатки тоже понятны: еще одна нотация, слишком сложно для простых случаев. Требует аккуратного обращения с терминологией. Сложно описывать случаи, которых не было, но тут помогает сказать "ну, а пусть ошиблись - что система должна делать". Сложно согласовывать, когда декомпозиция не совпадает с границами ответственности - учитывайте их.
👍6
Екатерина Герт из Крок. Ресурсный менеджер аналитиков - кто он такой? Для начала я хочу заметить, что название "ресурсный менеджер" для меня имеет резко отрицательную коннотацию отношения к людям как к заменяемым деталям в машине выполнения бизнес-процессов, с исключением личного отношения. У Екатерины этого отношения нет, да и в современном ИТ это невозможно, хотя лет 10-15 назад для крупных компаний было практически нормой. Но вот название должности у них в компании - осталось, и, наверное, внутри коннотаций не несет. Интересно, как это воспринимают другие участники. Может быть, оно и для других уже не несет таких коннотаций, получило новый смысл. А может, люди просто не задумываются, что на самом деле значит относиться к людям как к заменяемым ресурсам в машине бизнеса.
Ну а теперь - про содержание. Речь идет о позиции в профессионального руководителя при матричной организации, когда аналитики, разработчики, тестировщики работают в командах, задачи командам ставит продукт или проджект. И при этом специализации объединены в функциональные отделы, руководители которых решают задачи профессионального роста, дают обратную связь, найма, определения квалификации и зарплат, включая бюджеты, обучения и поддержки, решает конфликты с менеджером проекта, а также распределения аналитиков между проектами, именно с ними об этом договариваются менеджеры проектов. Аналитиков много, поэтому структура двухуровневая: есть тимлиды аналитиков, над которыми ресурсный менеджер. У нее 20 аналитиков. При этом ресурсный менеджер - 50%, вторая половина - ведущий аналитик в проекте. И нужен баланс между этими активностями. Ресурсный менеджер - супергерой, супергерои не могут выстроить день и не успевают на свою свадьбу. А по работе аналитика в проекте нужна предсказуемость.
Дальше быо детальное раскрытие работы. С кем работает?
* про людей: аналитики, HR-менеджеры;
* про бизнес: руководители направлений и владельцы продуктов - чтобы понять перспективные направления развития и потребности, финансовый директор - зарплаты и бюджеты;
* менеджеры продуктов и проектов - на стыке бизнеса и людей.
Дальше нагрузка по задачам, для ее ситуации с группой 20 человек
* Раз в год бюджет делаешь группы, и когда делаешь - большое погружение
* Мониторинг группы каждые полгода, подведение итогов
* итоги работы за квартал по группе, премии
* встречи с руководителем проекта и продукта 2 раза в месяц, планирование кто где работает
* встречи с HR-менеджером
* ведение ресурсного плана: сотрудники против проектов со сроками, чтобы во-время отслеживать изменения ситуацию
* встреча 1:1 с каждым аналитиком, 1-2 раза в месяц с каждым, отслеживание наставничества
Проблемы первого года работы, по убыванию. Хотя сортировка для нее не очевидна, но опрос дал именно ее.
* увольнение сотрудника
* негативная обратная связь
* бюджет (там же нужен прогноз премий и зарплат на год)
* зарплата и премии
* удержание сотрудника
* найм нового сотрудника
* подведение итогов сотрудника
Отмечу, что, возможно, именно потому, что подведение итогов полагают простым, люди как раз сталкиваются с удержанием и проблемами увольнения...
Как стать ресурсным менеджером? Для начала проверьте возможность, в вашей компании могут считать, что только проджект может стать, у них там было, потом компания выросла и требование отпало. Затем поговорить с руководителем, наметить план: рост до ведущего, пройти доп.обучение, начать работу с группой.
На этом все. И мне тут пришла вот какая мысль. Опыт Google говорит, что хорошие тимлиды получаются из средних, а не из ведущих разработчиков - ведущим это не интересно. Но тут - функциональное руководство и профессиональный рост, может действительно надо быть ведущим? С другой стороны, помимо роста тут куча административной работы, которая не слишком интересна ведущим. В общем, это может быть реликт старого традиционного подхода.
Ну а теперь - про содержание. Речь идет о позиции в профессионального руководителя при матричной организации, когда аналитики, разработчики, тестировщики работают в командах, задачи командам ставит продукт или проджект. И при этом специализации объединены в функциональные отделы, руководители которых решают задачи профессионального роста, дают обратную связь, найма, определения квалификации и зарплат, включая бюджеты, обучения и поддержки, решает конфликты с менеджером проекта, а также распределения аналитиков между проектами, именно с ними об этом договариваются менеджеры проектов. Аналитиков много, поэтому структура двухуровневая: есть тимлиды аналитиков, над которыми ресурсный менеджер. У нее 20 аналитиков. При этом ресурсный менеджер - 50%, вторая половина - ведущий аналитик в проекте. И нужен баланс между этими активностями. Ресурсный менеджер - супергерой, супергерои не могут выстроить день и не успевают на свою свадьбу. А по работе аналитика в проекте нужна предсказуемость.
Дальше быо детальное раскрытие работы. С кем работает?
* про людей: аналитики, HR-менеджеры;
* про бизнес: руководители направлений и владельцы продуктов - чтобы понять перспективные направления развития и потребности, финансовый директор - зарплаты и бюджеты;
* менеджеры продуктов и проектов - на стыке бизнеса и людей.
Дальше нагрузка по задачам, для ее ситуации с группой 20 человек
* Раз в год бюджет делаешь группы, и когда делаешь - большое погружение
* Мониторинг группы каждые полгода, подведение итогов
* итоги работы за квартал по группе, премии
* встречи с руководителем проекта и продукта 2 раза в месяц, планирование кто где работает
* встречи с HR-менеджером
* ведение ресурсного плана: сотрудники против проектов со сроками, чтобы во-время отслеживать изменения ситуацию
* встреча 1:1 с каждым аналитиком, 1-2 раза в месяц с каждым, отслеживание наставничества
Проблемы первого года работы, по убыванию. Хотя сортировка для нее не очевидна, но опрос дал именно ее.
* увольнение сотрудника
* негативная обратная связь
* бюджет (там же нужен прогноз премий и зарплат на год)
* зарплата и премии
* удержание сотрудника
* найм нового сотрудника
* подведение итогов сотрудника
Отмечу, что, возможно, именно потому, что подведение итогов полагают простым, люди как раз сталкиваются с удержанием и проблемами увольнения...
Как стать ресурсным менеджером? Для начала проверьте возможность, в вашей компании могут считать, что только проджект может стать, у них там было, потом компания выросла и требование отпало. Затем поговорить с руководителем, наметить план: рост до ведущего, пройти доп.обучение, начать работу с группой.
На этом все. И мне тут пришла вот какая мысль. Опыт Google говорит, что хорошие тимлиды получаются из средних, а не из ведущих разработчиков - ведущим это не интересно. Но тут - функциональное руководство и профессиональный рост, может действительно надо быть ведущим? С другой стороны, помимо роста тут куча административной работы, которая не слишком интересна ведущим. В общем, это может быть реликт старого традиционного подхода.
👍4
Ольга Ботнева. Боли аналитиков и эмоциональный интеллект как способ их лечения. Очень интересный доклад. Для начала была история про Марти Макфлая, герой трилогии "Назад в будущее". Он принимал решение под воздействием оценок других людей, провокаций. Но однажды сообразил: не надо так делать. Марти в этот момент включил эмоциональный интеллект, понял, что ожидают от него люди, вызывая определенные чувства, и перестал идти на поводу у манипуляторов.
Дальше был теоретический минимум. Эмоциональный интеллект - умение понимать эмоции других и, прежде сего, свои собственные: сначала надень маску на себя. Группы способностей: управление эмоциями (осознаем и контролируем), распознавание эмоций, использование эмоций (направляем эмоции на поддержку деятельности), понимание эмоций. Элементы эмоционального интеллекта - большой список: эмоциональное самосознание и самоконтроль, ориентация на результат, эмпатия и так далее. Помогает: общаться, настраивать отношения, стимулировать людей.
Мифы
* эмоциональная компетенция синоним эмоциональности (или безэмоциональности). Это не так, он просто управляет
* Человек с высоким EQ всегда в позитиве и в хорошем настроении. Нет. Он может кричать - когда нужно, управляемо
* EQ важнее чем IQ - нет. EQ про коммуникации, устройство на работу, а IQ - про интеллектуальный результат, нужны обе составляющих.
А дальше была самая интересная часть доклада. Ольга при подготовке провела исследование, опрос про боли аналитиков и способах, которыми они с этими болями справляются. И предложила те способы, которые в этих областях дадут методы эмоционального интеллекта. Это интересно не только с точки зрения методов эмоционального интеллекта, но и с точки зрения практик, которые люди применяют.
Проблемы понятные. Тяжело в коммуникациях: играть в принятые игры, общаться с малознакомыми, отсутствие коммуникаций в командах, отсутствие обратной связи, противостояние давлению и манипуляциям. Тяжело в самоощущениях: демонстрация неготовой функциональности, критика, ответственность за других; рутина и отсутствие творчества; сохранение лица в бесконечной коммуникации. ЭИ учит распознавать манипуляцию, сознательное вызывание эмоций, помогает понимать игры и включаться в них в игровой позиции без эмоционального накала, рекомендует составлять планы для общения повышение комфортности общения и так далее.
Про восстановление после авралов в презентации было много способов, которые аналитик применяют. А ЭИ говорит, что у нас есть 4 вида энергии: физическая, эмоциональная, интеллектуальная, духовная; надо понимать где дефицит, и для каждого вида есть свои рекомендации.
Дальше был теоретический минимум. Эмоциональный интеллект - умение понимать эмоции других и, прежде сего, свои собственные: сначала надень маску на себя. Группы способностей: управление эмоциями (осознаем и контролируем), распознавание эмоций, использование эмоций (направляем эмоции на поддержку деятельности), понимание эмоций. Элементы эмоционального интеллекта - большой список: эмоциональное самосознание и самоконтроль, ориентация на результат, эмпатия и так далее. Помогает: общаться, настраивать отношения, стимулировать людей.
Мифы
* эмоциональная компетенция синоним эмоциональности (или безэмоциональности). Это не так, он просто управляет
* Человек с высоким EQ всегда в позитиве и в хорошем настроении. Нет. Он может кричать - когда нужно, управляемо
* EQ важнее чем IQ - нет. EQ про коммуникации, устройство на работу, а IQ - про интеллектуальный результат, нужны обе составляющих.
А дальше была самая интересная часть доклада. Ольга при подготовке провела исследование, опрос про боли аналитиков и способах, которыми они с этими болями справляются. И предложила те способы, которые в этих областях дадут методы эмоционального интеллекта. Это интересно не только с точки зрения методов эмоционального интеллекта, но и с точки зрения практик, которые люди применяют.
Проблемы понятные. Тяжело в коммуникациях: играть в принятые игры, общаться с малознакомыми, отсутствие коммуникаций в командах, отсутствие обратной связи, противостояние давлению и манипуляциям. Тяжело в самоощущениях: демонстрация неготовой функциональности, критика, ответственность за других; рутина и отсутствие творчества; сохранение лица в бесконечной коммуникации. ЭИ учит распознавать манипуляцию, сознательное вызывание эмоций, помогает понимать игры и включаться в них в игровой позиции без эмоционального накала, рекомендует составлять планы для общения повышение комфортности общения и так далее.
Про восстановление после авралов в презентации было много способов, которые аналитик применяют. А ЭИ говорит, что у нас есть 4 вида энергии: физическая, эмоциональная, интеллектуальная, духовная; надо понимать где дефицит, и для каждого вида есть свои рекомендации.
👍3
Надежда Тарасова. Видение проекта: как повысить шансы проекта на успех. Видение описывает бизнес-требования к системе, цели, задачи, критерии успеха, ограничения. Надо не просто понять, а задокументировать и согласовать. Оно согласует ожидания заказчика с нашими намерениями, позволяет далее управлять ожиданиями и сравнивать фактическое продвижение с видением. Хорошее видение дает мотивацию команды. И дальше был рассказ, как его делать.
Понятные фазы
* Подготовка: шаблоны и примеры, чек-лист с вопросами, первый раунд заполнения по фазе пресейла, определение лакун
* Создание: циклично, с постоянной обратной связью и командной работой
* Финализация и утверждение, распространение и актуализация
Содержание
* Предпосылки и контекст - кто клиент; почему хочет инициировать проект; особенности ситуации компании-клиента; специфика и тренды индустрии
* Заинтересованные лица: клиент, мы, третьи стороны (консультанты). Уровни вовлеченности, области ответственности. Перепроверять, что не упустили, встречаемся лично, не забывайте тех, кто негативно настроен. Не все публично.
* Целевая аудитория (пользователи): узкая или широкая, прямая или косвенная, ядро ЦА, боли и проблемы, персоны. Частая ситуация: "сейчас делаем для себя, а потом будем продавать". А еще "не ходите к финансистам, у них сейчас отчеты." интересы пользователей и стейкхолдеров часто отличаться и даже противоречат: пользователи сайта знакомств хотят найти половину и не ходить ,а стейкхолдеры - чтобы вечно искали.
* Описание проблемы: выясняем, спрашиваем текущие решения, ставим приоритеты. Аккуратнее с формулировками, это бывает чувствительно. Не забываем про цели. Помним, что озвучивают субъективное мнение, а не объективные факты.
* Цели, задачи и критерии успеха. Выясняем и формулируем цели, описываем измеримые задачи, расставляем приоритеты. Очень часто тут нет конкретики. Можно предложить, но надо себя не загнать в них.
* Границы проекта. В целом и MVP, приоритеты. Сочетаем визуализация и текстовое представление. Стараемся уменьшить MVP.
* Риски, зависимости, допущения. Все, что успеем выяснить - записываем. Зависимости и допущения часто переходят в риски. Привлекаем всю команду.
* Ограничения. Стоимость: бюджет, скрытые затраты (лицензии и т.п.), неучтенные ожидания. Время: дедлайн, особые даты и события. Границы: MVP, особые сценарии, нефункциональные требования.
* Что еще: маркетинговые исследования, внутренняя статистика, процессы AsIs и ToBe, требования к переходу, макеты, оценки трудозатрат и так далее - уровень подготовки проекта может быть разным.
Рекомендации.
* Стараемся понять и описать видения до того, как займемся деталями реализации. Не всегда работает, заказчику может быть все ясно.
* Адаптируем размер и содержание под специфику проекта
* Визуализируем и презентуем. Документы не читают, поэтому сделайте презентацию с важным.
* Доносим до команды. Не просто отдаем ей готовые документы и другие результаты, рассказываем. И потом тоже взаимодействуем, даже если ушли на другой проект.
* Следим за актуальностью. Сверяемся в ходе разработке проекта.
Понятные фазы
* Подготовка: шаблоны и примеры, чек-лист с вопросами, первый раунд заполнения по фазе пресейла, определение лакун
* Создание: циклично, с постоянной обратной связью и командной работой
* Финализация и утверждение, распространение и актуализация
Содержание
* Предпосылки и контекст - кто клиент; почему хочет инициировать проект; особенности ситуации компании-клиента; специфика и тренды индустрии
* Заинтересованные лица: клиент, мы, третьи стороны (консультанты). Уровни вовлеченности, области ответственности. Перепроверять, что не упустили, встречаемся лично, не забывайте тех, кто негативно настроен. Не все публично.
* Целевая аудитория (пользователи): узкая или широкая, прямая или косвенная, ядро ЦА, боли и проблемы, персоны. Частая ситуация: "сейчас делаем для себя, а потом будем продавать". А еще "не ходите к финансистам, у них сейчас отчеты." интересы пользователей и стейкхолдеров часто отличаться и даже противоречат: пользователи сайта знакомств хотят найти половину и не ходить ,а стейкхолдеры - чтобы вечно искали.
* Описание проблемы: выясняем, спрашиваем текущие решения, ставим приоритеты. Аккуратнее с формулировками, это бывает чувствительно. Не забываем про цели. Помним, что озвучивают субъективное мнение, а не объективные факты.
* Цели, задачи и критерии успеха. Выясняем и формулируем цели, описываем измеримые задачи, расставляем приоритеты. Очень часто тут нет конкретики. Можно предложить, но надо себя не загнать в них.
* Границы проекта. В целом и MVP, приоритеты. Сочетаем визуализация и текстовое представление. Стараемся уменьшить MVP.
* Риски, зависимости, допущения. Все, что успеем выяснить - записываем. Зависимости и допущения часто переходят в риски. Привлекаем всю команду.
* Ограничения. Стоимость: бюджет, скрытые затраты (лицензии и т.п.), неучтенные ожидания. Время: дедлайн, особые даты и события. Границы: MVP, особые сценарии, нефункциональные требования.
* Что еще: маркетинговые исследования, внутренняя статистика, процессы AsIs и ToBe, требования к переходу, макеты, оценки трудозатрат и так далее - уровень подготовки проекта может быть разным.
Рекомендации.
* Стараемся понять и описать видения до того, как займемся деталями реализации. Не всегда работает, заказчику может быть все ясно.
* Адаптируем размер и содержание под специфику проекта
* Визуализируем и презентуем. Документы не читают, поэтому сделайте презентацию с важным.
* Доносим до команды. Не просто отдаем ей готовые документы и другие результаты, рассказываем. И потом тоже взаимодействуем, даже если ушли на другой проект.
* Следим за актуальностью. Сверяемся в ходе разработке проекта.
Татьяна Половинкина. Данные в комиксах: От источников до дельты. В докладе был некоторый ликбез по работе аналитика данных как новой специализации, дополняющей существующие специализации бизнес-аналитика и системного аналитика. Отличие в том, что он работает с динамическим потоком данных, строя архитектуру обработки и обеспечивая пользователей нужными данными. Специализация в процессе формирования, так что тут нет устойчивого процесса и терминологии. Но при этом контекст достаточно объемный.
* Фазы понятные: планирование, проектирование, создание-получение, хранение-обслуживание-архивирование, использование. Но потоки данных - меняются, хранение - деформируется.
* Фокусы: осмысленность данных, выгода использования. Доступность в условиях изменчивости. Масштабируемость. Качественность, доверие данным. Безопасность данных. Температура данных - частота обращения.
* Виды данных: Small (обычные БД), Big (с ними просто не получится), Smart (информативные данные, Fast (выявление Smart в Big, Темные (это что мы не знаем).
* Деление по хранению: Широкие (много колонок) Длинные (много строк).
* Сегментирование - партиционирование - шардирование: деление больших данных на группы.
* Виртуализация данных: они лежат везде, 60-70источников - обычная история, идея - промежуточный уровень для абстрагирование от изменений в конкретных источниках.
* Качество данных. Тут много характеристик, было 4, теперь 20.
* Безопасность: генерация, маскирование, шифрование. Маскирование всегда необратимо, а отличие от шифрования, при этом маскирование может быть частичным.
* Обогащение данных. Это не только дополнение, это еще удаление ненужных данных, маскирование для увеличения доступности.
* Фазы понятные: планирование, проектирование, создание-получение, хранение-обслуживание-архивирование, использование. Но потоки данных - меняются, хранение - деформируется.
* Фокусы: осмысленность данных, выгода использования. Доступность в условиях изменчивости. Масштабируемость. Качественность, доверие данным. Безопасность данных. Температура данных - частота обращения.
* Виды данных: Small (обычные БД), Big (с ними просто не получится), Smart (информативные данные, Fast (выявление Smart в Big, Темные (это что мы не знаем).
* Деление по хранению: Широкие (много колонок) Длинные (много строк).
* Сегментирование - партиционирование - шардирование: деление больших данных на группы.
* Виртуализация данных: они лежат везде, 60-70источников - обычная история, идея - промежуточный уровень для абстрагирование от изменений в конкретных источниках.
* Качество данных. Тут много характеристик, было 4, теперь 20.
* Безопасность: генерация, маскирование, шифрование. Маскирование всегда необратимо, а отличие от шифрования, при этом маскирование может быть частичным.
* Обогащение данных. Это не только дополнение, это еще удаление ненужных данных, маскирование для увеличения доступности.
🔥2
Денис Позднев. Личная база знаний или как не потеряться в информационном шуме. Есть много способов вести заметки, которые превращаются в базу знаний: OneNote, EverNote, Notion. Но у первых двух нет ссылок между заметками, Notion - попробовали решить ссылки через Базу данных, но там все сложно. А главное у них проплиетарное хранение в облаке, и если что - ваша база данных у вас пропала.
Obsidian - markdown в тестовых файлах. Структура - папки. Механизм шаблонов, за счет которого быстро делаем страницу. Например, хотим описывать книги - делаем шаблон "цитата" - там текст, ссылка на источник, свои мысли. И описание книги - тоже шаблон с автором, идеями и так далее. Markdown позволяет делать ссылки - и obsidian умеет рисовать граф ссылок между статьями. При этом граф можно фильтровать.
Obsidian позволяет подключать внешние плагины. Есть плагин, который формирует таблицы по заметкам. Например, если вы делали заметки по книгам - то можно делать разные списки книг. Plugin Calendar. Плагинов много, они пополняются. Поддерживает JScript и Closure - и можно делать запросы и визуализировать по-своему.
Синхронизация в облака - стандартными способами перетирает заметки, но сообщество сделало собственный плагин, с ним проблем у него не было. Есть возможность синхронизации в git.
Еще надо отметить следующее. Есть методология ведения заметок Zettelkasten, и Obsidian ее поддерживает. Но он эту методологию не использует, потому что при следовании ей получается нечитаемый каталог. Он предпочитает самому формировать структуру каталогов и использовать механизм шаблонов.
Obsidian - markdown в тестовых файлах. Структура - папки. Механизм шаблонов, за счет которого быстро делаем страницу. Например, хотим описывать книги - делаем шаблон "цитата" - там текст, ссылка на источник, свои мысли. И описание книги - тоже шаблон с автором, идеями и так далее. Markdown позволяет делать ссылки - и obsidian умеет рисовать граф ссылок между статьями. При этом граф можно фильтровать.
Obsidian позволяет подключать внешние плагины. Есть плагин, который формирует таблицы по заметкам. Например, если вы делали заметки по книгам - то можно делать разные списки книг. Plugin Calendar. Плагинов много, они пополняются. Поддерживает JScript и Closure - и можно делать запросы и визуализировать по-своему.
Синхронизация в облака - стандартными способами перетирает заметки, но сообщество сделало собственный плагин, с ним проблем у него не было. Есть возможность синхронизации в git.
Еще надо отметить следующее. Есть методология ведения заметок Zettelkasten, и Obsidian ее поддерживает. Но он эту методологию не использует, потому что при следовании ей получается нечитаемый каталог. Он предпочитает самому формировать структуру каталогов и использовать механизм шаблонов.
Антон Семенченко. Когнитивное здоровье в IT. У Антона уже было несколько докладов, подготовленных вместе с профессиональным психиатром, знакомящих с психологическими моделями в разных аспектах. В этом докладе речь шла про когнитивные функции и интеллект. При этом Антон не просто рассказывает модели, он их приземляет на материал ИТ, работу аналитика. Например, все знают, что у человека есть бессознательное. Но проводя интервью аналитики обычно не задаются вопросами, действительно ли заказчик не знает ответа на какой-то вопрос или не владеет ситуацией, или у него это знание есть, только в бессознательной области, и он осознанно или неосознанно предпринимает усилия, чтобы вы тоже не поняли истинную ситуацию. Неявно предполагается, что аналитики работают в поле рационального мышления и в эти вопросы не погружаются. Хотя понимание таких аспектов может быть полезно.
Доклад начался длинным списком когнитивных функций: память, речь, психомоторика, речь, гнозис, праксис, счет и письмо, мышление, еще ряд пунктов и только в конце интеллект. Отмечу, что далеко не все слова мне знакомы, так что я еще этот список посмотрю, а слова - погуглю. Еще в докладе была большая схема психики, которую тоже надо поразглядывать и еще несколько подобных слайдов, которые Антон не рассказывал, а оставил как материалы для самостоятельного изучения.
Измерение интеллекта. Тест Векслера IQ - плохая метрика лучше отсутствия. Используется в судебной медицине. <70 - умственно отсталый и ограниченно вменяемый, от 100 умный, от 120 очень умный, а вот от 140 - слишком умный, обычно есть проблемы в адаптации и социализации.
Про бессознательное. Тут надо понимать, что есть ряд теорий бессознательного, которые по-разному его объясняют.
* Есть теория непрерывности сознания, идет от Лейбница и Сеченова.
* Другая крайность - бессознательное как нечто отличное от сознания, это Гартман, Шопенгауэр.
* Дюркгейм. Сознание как способ приспособления к среде. Есть биологическая сущность и социальная сущность, они противоречат.
* Бессознательное по Фрейду и далее - Юнгу. Биологические инстинкты, желания, чувства, аффекты. Предсознание - волевая регуляция.
В зависимости от используемой теории ответ на вопрос, действительно ли заказчик не знает ответа на ваши вопросы или скрывает их в бессознательном, и что вам с этим делать, будет разным.
Переход количества в в качества - появление сознания в ходе эволюции у жевотных. Муравьи со своим языком, передача сигналов, счет до 58. Гориллы обучаются до уровня 6-8 летнего ребенка. Характер, психотравмы и атк далее. И у хомячков, не говоря о крысах.
Современное представление: сознания и бессознательное в гармоничном единстве. Сфера ясного сознания невелика.
Ощущение и восприятие. Сенсорная депривация и стимуляция у детей связаны с психическим развитием. Интонации и невербалика.
* Американские эксперименты на детях с лишением привычного потока сенсорной информации. Или с монотонным общением - это мама-психиатр над своим ребенком издевалась.
* Эксперименты на африканских детях. Оказывается, они более развиты до некоторого момента, чем европейские - потому что они всегда с родителями, их всюду таскают. И это дает больше, чем целенаправленное развитие в специальных условиях, но с ограниченным контактом с миром. Позднее картина меняется - потому как целенаправленное обучение все-таки срабатывает.
Мышление. Абстрагирование, Объектно-Ориентированное программирование. Восприятие картинок, абстрактный стол. Есть первобытные племена, где оно слабо развито - не было нужно. Не стоит удивляться, если у Заказчика не развито абстрагирование.
Я тут отмечу, что дихотомия Сенсорик - Интуит Майерс-Бриггс по сути меряет уровень абстрактного мышления и частоту его использования по сравнению с мозаичным мышлением из отдельных деталей.
Доклад начался длинным списком когнитивных функций: память, речь, психомоторика, речь, гнозис, праксис, счет и письмо, мышление, еще ряд пунктов и только в конце интеллект. Отмечу, что далеко не все слова мне знакомы, так что я еще этот список посмотрю, а слова - погуглю. Еще в докладе была большая схема психики, которую тоже надо поразглядывать и еще несколько подобных слайдов, которые Антон не рассказывал, а оставил как материалы для самостоятельного изучения.
Измерение интеллекта. Тест Векслера IQ - плохая метрика лучше отсутствия. Используется в судебной медицине. <70 - умственно отсталый и ограниченно вменяемый, от 100 умный, от 120 очень умный, а вот от 140 - слишком умный, обычно есть проблемы в адаптации и социализации.
Про бессознательное. Тут надо понимать, что есть ряд теорий бессознательного, которые по-разному его объясняют.
* Есть теория непрерывности сознания, идет от Лейбница и Сеченова.
* Другая крайность - бессознательное как нечто отличное от сознания, это Гартман, Шопенгауэр.
* Дюркгейм. Сознание как способ приспособления к среде. Есть биологическая сущность и социальная сущность, они противоречат.
* Бессознательное по Фрейду и далее - Юнгу. Биологические инстинкты, желания, чувства, аффекты. Предсознание - волевая регуляция.
В зависимости от используемой теории ответ на вопрос, действительно ли заказчик не знает ответа на ваши вопросы или скрывает их в бессознательном, и что вам с этим делать, будет разным.
Переход количества в в качества - появление сознания в ходе эволюции у жевотных. Муравьи со своим языком, передача сигналов, счет до 58. Гориллы обучаются до уровня 6-8 летнего ребенка. Характер, психотравмы и атк далее. И у хомячков, не говоря о крысах.
Современное представление: сознания и бессознательное в гармоничном единстве. Сфера ясного сознания невелика.
Ощущение и восприятие. Сенсорная депривация и стимуляция у детей связаны с психическим развитием. Интонации и невербалика.
* Американские эксперименты на детях с лишением привычного потока сенсорной информации. Или с монотонным общением - это мама-психиатр над своим ребенком издевалась.
* Эксперименты на африканских детях. Оказывается, они более развиты до некоторого момента, чем европейские - потому что они всегда с родителями, их всюду таскают. И это дает больше, чем целенаправленное развитие в специальных условиях, но с ограниченным контактом с миром. Позднее картина меняется - потому как целенаправленное обучение все-таки срабатывает.
Мышление. Абстрагирование, Объектно-Ориентированное программирование. Восприятие картинок, абстрактный стол. Есть первобытные племена, где оно слабо развито - не было нужно. Не стоит удивляться, если у Заказчика не развито абстрагирование.
Я тут отмечу, что дихотомия Сенсорик - Интуит Майерс-Бриггс по сути меряет уровень абстрактного мышления и частоту его использования по сравнению с мозаичным мышлением из отдельных деталей.
👍2
Мышление.
* Цель мышления - вывод ответа, решение задач. Проверка гипотез. Этим занимается когнитивная система и в ней есть баги.
* Методы: Обобщение, Классификация, Абстракция.
* Виды: Предметно-действенное - до 3 лет. Наглядно-образное - может быть сложное, но очень сложно ложится на алгоритмизацию. Словесно-логическое или понятийное. Два полушария, фокусировка одного на наглядно-образном, другое на словесно-логическим.
Конкретное мышление: не понимают метафоры типа золотые руки, светлая голова, черное сердце. Вопросы что тяжелее килограмм пуха или килограмм железа; что быстрее - птица или самолет.
Переобучение. У него опыт обучения программирования. В целом осваивают все. Но когда у человека образное мышление, от художественной школы и т.п. И когда алгоритмизация не идет, он не понимает "есть три числа и что-то сделать" - у него не развит этот навык. И заказчик тоже может быть с не развитым навыком.
Разговор с уточкой. Объясняешь другому - и наконец-то сам понимаешь.
Память - совокупность процессов, обеспечивающих запечатление. Не путать с вниманием, возможности фокусировки. Часто проблемы с фокусировкой принимают за проблемы с памятью - а ты просто не запоминаешь. Память зависит от повторения - забывание перед экзаменом. Лучше каждый день и небольшими порциями - перейдет в активный багаж. А не короткими модулями.
Хочу отметить, что это поднимает вопрос с целесообразностью модульного обучения. Да, в моменте ты от погружения запоминаешь лучше, но потом без активного использования ты это забываешь быстрее.
Эффект Зейгарник. Заканчивайте на самом интересном месте.
Рекомендации
* учить язык каждый день 5-10 минут, читать по 5 страниц дважды каждый день
* магическое число 7+-2. Задача Эйнштейна, решить без бумаги - потому что надо держать много сущностей.
* Инженерные практики: цикломатическая сложность (7-9), количество реализуемых интерфейсов (5), количество методов до 9, глубина наследования до 5 - чтобы все это помещалось в голову.
Виды памяти - двигательная, образная, эмоциональная и так далее.
Рекомендация для запоминания - мелкая моторика, доски и маркеры, механическая клавиатура, беседа с уточкой, организация офиса (дартс, пинг-понг, турник, xbox). Виды внимания: непроизвольное, произвольное-волевое, послепроизвольное...
Follow ups - необходимость, иначе мысли размазываются и несфокусированные. Не только по встречам и созвонам, но и обсуждению с чатиками. Потому что когнитивные искажения, несосредоточенное внимание.
Примеры по повышении зарплаты, квалификации, премии - много примеров когда сотрудник уверен, когда после пары книг гарантированно повысят, а руководитель уверен, что внятно объяснил, что ему столько еще надо сделать, что будет не скоро.
* Цель мышления - вывод ответа, решение задач. Проверка гипотез. Этим занимается когнитивная система и в ней есть баги.
* Методы: Обобщение, Классификация, Абстракция.
* Виды: Предметно-действенное - до 3 лет. Наглядно-образное - может быть сложное, но очень сложно ложится на алгоритмизацию. Словесно-логическое или понятийное. Два полушария, фокусировка одного на наглядно-образном, другое на словесно-логическим.
Конкретное мышление: не понимают метафоры типа золотые руки, светлая голова, черное сердце. Вопросы что тяжелее килограмм пуха или килограмм железа; что быстрее - птица или самолет.
Переобучение. У него опыт обучения программирования. В целом осваивают все. Но когда у человека образное мышление, от художественной школы и т.п. И когда алгоритмизация не идет, он не понимает "есть три числа и что-то сделать" - у него не развит этот навык. И заказчик тоже может быть с не развитым навыком.
Разговор с уточкой. Объясняешь другому - и наконец-то сам понимаешь.
Память - совокупность процессов, обеспечивающих запечатление. Не путать с вниманием, возможности фокусировки. Часто проблемы с фокусировкой принимают за проблемы с памятью - а ты просто не запоминаешь. Память зависит от повторения - забывание перед экзаменом. Лучше каждый день и небольшими порциями - перейдет в активный багаж. А не короткими модулями.
Хочу отметить, что это поднимает вопрос с целесообразностью модульного обучения. Да, в моменте ты от погружения запоминаешь лучше, но потом без активного использования ты это забываешь быстрее.
Эффект Зейгарник. Заканчивайте на самом интересном месте.
Рекомендации
* учить язык каждый день 5-10 минут, читать по 5 страниц дважды каждый день
* магическое число 7+-2. Задача Эйнштейна, решить без бумаги - потому что надо держать много сущностей.
* Инженерные практики: цикломатическая сложность (7-9), количество реализуемых интерфейсов (5), количество методов до 9, глубина наследования до 5 - чтобы все это помещалось в голову.
Виды памяти - двигательная, образная, эмоциональная и так далее.
Рекомендация для запоминания - мелкая моторика, доски и маркеры, механическая клавиатура, беседа с уточкой, организация офиса (дартс, пинг-понг, турник, xbox). Виды внимания: непроизвольное, произвольное-волевое, послепроизвольное...
Follow ups - необходимость, иначе мысли размазываются и несфокусированные. Не только по встречам и созвонам, но и обсуждению с чатиками. Потому что когнитивные искажения, несосредоточенное внимание.
Примеры по повышении зарплаты, квалификации, премии - много примеров когда сотрудник уверен, когда после пары книг гарантированно повысят, а руководитель уверен, что внятно объяснил, что ему столько еще надо сделать, что будет не скоро.
👍2
Юрий Дручинин. Поддержка принятия решений в продуктовом стартапе. Обзорный доклад про особенности разработки продуктов. Много интересного, часть слайдов - для подробного разглядывания и гуления, их проскакивали в рассказе.
Продукт несет ответственность за принятие решений, аналитик должен предоставлять основания. Проблема в том, что для многих решений Аналитик не может предоставить основания. Продукт их все равно примет, хотелось бы, чтобы аналитик помог.
* Каждый шаг - деньги - нужно основание
* лучшее основание - валидные цифровые данные
* решение исполнено - надо оценить результат
* лучшее оценка исполнения - рост цифр
* Decision Execution Management - DXM - это очень дорого
* Минутки и заметки со встреч - DXM на минималках
Главное перестроение мышления: все что приходит в голову ему или продукту - это гипотеза. Поэтому не надо бросаться делать, надо остановиться и сказать: с чего бы это? Каждая гипотеза распадается на три: гипотеза проблемы (у пользователя есть проблема), гипотеза решения (решает проблему), гипотеза ценности (решение ценно пользователю, он готов платить). Много людей восторгаются продуктами и фичами, но платить за них не готовы.
В докладе фокус на гипотезе решения. Распадается на две: What (какую фичу реализуем) и How (как ее реализуем).
* What. Часто очевидные шаги, то что есть у конкурентов - не аргумент, большие рискованные шаги. Но быстро понятно, когда идете не туда.
* How - можно сделать по-разному, формально и просто, либо большой проработкой пользовательского опыта. Это влияет на имидж продукта. И они дают кумулятивный эффект. Аналитик тут может помогать и подсвечивать слепые зоны. У него mindset копать в детали даже простую фичу и из-за этого могут не попадать в сроки.
Три доминанты в каждой команде: продукт (много счастливых пользователей), проджект (сроки и бюджет) и техлид (техническое совершенство и отсутствие рисков). Иногда их совмещает один человек, но это - разные пласты, и они плохо сочетаются. Аналитик должен видеть майндсеты, их соответствие позициям и напоминать.
Контексты решений
* Активности продукта: поиск, проектирование, разработка и поставка, развитие
* Жизненный цикл разработки: анализ, дизайн, разработка, релиз, поставка, эксплуатация. И мониторинг
* Жизненный цикл продукта
SWOT-анализ и PESTEL. Делаются, но игнорируются, и потому делаются поверхностно. Когда наняли продукта, решение о стартапе принято. Хотя это была гипотеза, и ее стоит проверять. Но для этого от продукта нужна смелость. И надо копать в недостатки и Угрозы, Преимущества и Возможности Продукт прокапает сам.
Product Vision как артефакт. Нужно для решения о деньгах. Надо собрать основания. На слайде - конкретное содержание, 10 пунктов, включая Lean canvas.
CJM и USM.
* На действующем продукте строим CJM - продукт есть. И вокруг него USM, выделяя активности и провалы.
* На стадии стартапа наоборот, строим USM, и дальше на основе опросов пользователи конкурирующего продукта делаем CJM.
Основной источник фич - USM. Но дальше надо позиционировать фичи, с учетом реализации конкурентов, ожиданий пользователей, объемов реализации.
Гипотезы - HADI-циклы
* Очень плохо работает на старте, так как не видна разница между проверкой гипотезы и разработкой.
* Наиболее эффективно - на growth
* Плохо проверяет What, хорошо How
Roadmap. Когда напилили на фичи - декомпозировали по ролям и раскладываем. Product increment у них 6 спринтов. Но! На старте нет требований, нет понимания в деталях. Поэтому резервируем место. А далее попадаем в сроки через варьирование бантиков.
Сегментация аудитории - только тогда, когда понимаем состояние продукта, которое можем транслировать в рынок. Понятно, что гипотезы были. ABCX сегментации. Понимайте, что сегмент X может убить продукт. Не дай бог продукт вашего self-made стартапа захочет на ранней стадии купить госбанк, которому нужно ИБ и много другого - это угробит незрелый продукт.
Квадраты по определенности для продукта, стейкхолдера и клиента.
Сущности и скоуп продукта. Диаграмма классов - первое, что просит от аналитика. Оно хорошо обрисовывает скоуп продукта.
Продукт несет ответственность за принятие решений, аналитик должен предоставлять основания. Проблема в том, что для многих решений Аналитик не может предоставить основания. Продукт их все равно примет, хотелось бы, чтобы аналитик помог.
* Каждый шаг - деньги - нужно основание
* лучшее основание - валидные цифровые данные
* решение исполнено - надо оценить результат
* лучшее оценка исполнения - рост цифр
* Decision Execution Management - DXM - это очень дорого
* Минутки и заметки со встреч - DXM на минималках
Главное перестроение мышления: все что приходит в голову ему или продукту - это гипотеза. Поэтому не надо бросаться делать, надо остановиться и сказать: с чего бы это? Каждая гипотеза распадается на три: гипотеза проблемы (у пользователя есть проблема), гипотеза решения (решает проблему), гипотеза ценности (решение ценно пользователю, он готов платить). Много людей восторгаются продуктами и фичами, но платить за них не готовы.
В докладе фокус на гипотезе решения. Распадается на две: What (какую фичу реализуем) и How (как ее реализуем).
* What. Часто очевидные шаги, то что есть у конкурентов - не аргумент, большие рискованные шаги. Но быстро понятно, когда идете не туда.
* How - можно сделать по-разному, формально и просто, либо большой проработкой пользовательского опыта. Это влияет на имидж продукта. И они дают кумулятивный эффект. Аналитик тут может помогать и подсвечивать слепые зоны. У него mindset копать в детали даже простую фичу и из-за этого могут не попадать в сроки.
Три доминанты в каждой команде: продукт (много счастливых пользователей), проджект (сроки и бюджет) и техлид (техническое совершенство и отсутствие рисков). Иногда их совмещает один человек, но это - разные пласты, и они плохо сочетаются. Аналитик должен видеть майндсеты, их соответствие позициям и напоминать.
Контексты решений
* Активности продукта: поиск, проектирование, разработка и поставка, развитие
* Жизненный цикл разработки: анализ, дизайн, разработка, релиз, поставка, эксплуатация. И мониторинг
* Жизненный цикл продукта
SWOT-анализ и PESTEL. Делаются, но игнорируются, и потому делаются поверхностно. Когда наняли продукта, решение о стартапе принято. Хотя это была гипотеза, и ее стоит проверять. Но для этого от продукта нужна смелость. И надо копать в недостатки и Угрозы, Преимущества и Возможности Продукт прокапает сам.
Product Vision как артефакт. Нужно для решения о деньгах. Надо собрать основания. На слайде - конкретное содержание, 10 пунктов, включая Lean canvas.
CJM и USM.
* На действующем продукте строим CJM - продукт есть. И вокруг него USM, выделяя активности и провалы.
* На стадии стартапа наоборот, строим USM, и дальше на основе опросов пользователи конкурирующего продукта делаем CJM.
Основной источник фич - USM. Но дальше надо позиционировать фичи, с учетом реализации конкурентов, ожиданий пользователей, объемов реализации.
Гипотезы - HADI-циклы
* Очень плохо работает на старте, так как не видна разница между проверкой гипотезы и разработкой.
* Наиболее эффективно - на growth
* Плохо проверяет What, хорошо How
Roadmap. Когда напилили на фичи - декомпозировали по ролям и раскладываем. Product increment у них 6 спринтов. Но! На старте нет требований, нет понимания в деталях. Поэтому резервируем место. А далее попадаем в сроки через варьирование бантиков.
Сегментация аудитории - только тогда, когда понимаем состояние продукта, которое можем транслировать в рынок. Понятно, что гипотезы были. ABCX сегментации. Понимайте, что сегмент X может убить продукт. Не дай бог продукт вашего self-made стартапа захочет на ранней стадии купить госбанк, которому нужно ИБ и много другого - это угробит незрелый продукт.
Квадраты по определенности для продукта, стейкхолдера и клиента.
Сущности и скоуп продукта. Диаграмма классов - первое, что просит от аналитика. Оно хорошо обрисовывает скоуп продукта.
👍2