Спасибо большое за отклик — особенно ценно услышать мнение от коллеги с похожим опытом из другой области.
С джунами действительно важно удерживать баланс: мягкость помогает выстроить доверие, но если ошибки повторяются или нарушаются договоренности — я стараюсь говорить строже, но при этом сохранять открытый диалог.
Спасибо, что подсветили тему развития — очень важная и точно достойна отдельного разговора.
Спасибо за интерес к статье и нашей команде :) Можешь отправить резюме на job@naumen.ru — мы сохраним твои контакты и свяжемся, как только появится подходящая вакансия.
Спасибо за вопрос! Это была задача от заказчика по ручному анализу и очистке входящих данных в Excel. Тогда автоматизировать подобные процессы не получалось, поэтому задача относилась к зоне ответственности бизнеса — нужно было хорошо разбираться в специфике данных в их сфере. Мне же нужно было работать уже с актуальными данными.
Оба подхода обладают своими плюсами и минусами, серебряной пули, к сожалению, не существует. EAV использовался в проектном решении этой задачи, но таблица разрастается довольно быстро, и это может начать создавать проблемы производительности.
Что касается JSONB, то под капотом в случае с Postgres используется именно он — как более эффективный.
Привет! Спасибо, что высказал интересную мысль :) Мы всегда открыты к новым идеям, так что ты можешь написать нам в Telegram @naumen_connect, сможем подробнее обсудить формат, который тебе кажется перспективным.
Добрый день! Конечно, посчитать точно возможности нет, всегда есть приближенные расчеты.
Мы считаем, что повлияли именно изменения в продукте, так как «соседний» продукт для внутренней поддержки не вырос настолько же в тех же условиях рынка, когда началось импортозамещение. При этом исторически видели, что оба продукта примерно одинаково реагировали на волнения на рынке.
Я не встречал методик по определению уровня неопределенности. Существуют методы оценки риска, да. Но это другое. Суть mindmap, о котором идет речь в статье (можно посмотреть здесь: https://miro.com/app/board/uXjVNEOGewU=/), чтобы иметь инструмент для определения составляющих (аспектов), по которым мы, возможно, не учли какие-то требования. И далее, что делать, чтобы выявить и формализовать эти требования.
Проблема в статье рассматривается не с точки зрения менеджмента, а с точки зрения результативности команды. Конечно, это более актуально, когда формат договора предполагает обоюдную ответственность для заказчика и исполнителя, как, например, в fixed price & fixed scope. А еще более значимо во внутренней разработке.
Оценить рамки неопределенности как раз и помогает mindmap. Чтобы было понятнее, вот ссылка: https://miro.com/app/board/uXjVNEOGewU=/. Чем раньше с его помощью получится понять, что есть «слепые зоны», тем лучше для всех.
Если кратко, то: первое — наши хорошо отлаженные процессы позволяют проводить подобные обновления, второе — как отметил в статье, каждое обновление приносит с собой и улучшение языка, и повышение безопасности и перформанса продукта из коробки.
Клиентоориентированность — общая тенденция. Сейчас она применяется почти везде. В проектном подходе мы ориентируемся на конкретного клиента, для которого реализуем проект. А в продуктовом — на большинство клиентов, имеющих схожие потребности.
Процессный подход относится к другой категории. То есть его некорректно сравнивать или противопоставлять продуктовому подходу, о котором говорим в статье.
Когда собеседник не знает/не понимает конечную цель или не может ее сформулировать, он отвечает простыми и понятными ему вещами — рутинными действиями. Я это называю «Я работаю, чтобы делать свою работу».
Для того, чтобы копнуть глубже, использую метод «5 почему». Приведу пример из жизни, который рассказывал своим коллегам:
— Я хочу купить машину.
— Зачем?
— Чтобы ездить.
— Куда ты собираешься на ней ездить?
— Я хочу ездить на ней на работу.
— Ты можешь добираться на автобусе или на метро, это быстрее и без пробок. Для чего машина?
— Утром я хочу выезжать пораньше, чтобы успевать отвозить детей в детский сад, который находится на другом конце города. Потом добираться до офиса. После работы забирать детей из детского сада и возвращаться пораньше, чтобы успеть к ужину, который приготовила жена, после провести время с ней. А еще вспомнил, что хочу иногда ездить на базу отдыха за городом и не быть привязанным к расписанию электричек.
В этом примере мы натыкаемся на умение формулировать цель действия — покупки машины. Мы получили ответ «действие». Затем задали второй уточняющий вопрос и все равно получили ответ в виде действия. Лишь на третьем вопросе, копнув глубже, мы получили развернутый ответ и узнали те цели, которые преследует собеседник.
В проектах автоматизации мы натыкаемся на аналогичные случаи. Например, заказчик просит сделать в задаче даты планового и фактического выполнения. Его мотивация на поверхности — хочу видеть, какие сотрудники вовремя выполняют задачи. Если начать копать зачем, почему, когда — мы выясним: что он хочет каждый день видеть, какие сотрудники не укладываются в срок и по каким задачам. В ходе диалога мы понимаем, что ему нужна не просто дата, а еще и ежедневный удобный отчет. Пользователь не знал, что мы можем быстро настроить ему выгрузку, поэтому опирался на свой прошлый опыт — визуально бы сравнивал в экселе.
Решили выделить роль администратора из-за большой нагрузки на РП. В ответственность РП входит все вами перечисленное.
Мы ведем как записи встреч, если это возможно, так и протоколы, которые чаще пишут администраторы. В протоколах фиксируем, какие вопросы обсуждали и какие решения приняли. Поэтому нить проекта РП не упускает. К тому же, РП сам может зафиксировать важные для себя моменты.
Чтобы лучше понять разницу между процессным, проектным и продуктовым подходом, можно познакомиться со «стоматологической» аналогией.
Мы не оцениваем проектный и продуктовый подходы с точки зрения плохой или хороший —каждый из них применим в разных ситуациях. Для закрытия уникальной потребности лучше всего подойдет проект. А для решения типовых задач, повторяющихся у разных заказчиков, оптимален продукт
Считать ли типовые проекты продуктом? Это зависит от подхода, применяемого при реализации этих типовых проектов. Если каждый раз они выполняются «с нуля», без использования предыдущего опыта, то продуктом это назвать сложно. Если же есть типовые решения, которые применяются из раза в раз при совпадении исходных условий, то это уже ближе к продукту. А если эти типовые решения не просто применяются, но и анализируется опыт их использования, оптимизируется их функционал на основе этого анализа, то смело можем говорить о продуктовом решении.
Группа администрирования работает не только на проектах внедрения, а занимается отчетами, учетом лицензий, организацией обучения клиентов, организацией рабочего пространства для сотрудников подразделения и т.д. Также в практике два направления: продуктовое и центр внедрения. Группа администрирования работает на оба: например, тот же технический писатель занимается как проектной документацией, так и документацией для продуктов.
Если бы РП был прямым руководителем этой группы, на него легла бы дополнительная нагрузка — в виде распределения и контроля всех этих задач. Сейчас это делает Света.
Света управляет командой из двух человек, поэтому, помимо задач администратора, готовит отчёты и распределяет активности внутри своей группы. В команде Светы есть технический писатель и ещё один администратор — так как проектов в работе много, один администратор бы не справился :) Поэтому было решено создать отдельную команду, которая помогает бизнесу.
Добрый день! Продукт построен на основе платформы Naumen SMP, над которой работает большая команда в компании. Так как платформа low-code, то небольшие автоматизации пишут все продуктовые аналитики. А наибольших успехов достиг Андрей :)
Добрый день! Это неотчуждаемый от особенностей нашей системы механизм, так как много логики завязано на тонкости нашей платформы. Возможно, в будущем, если у нас получится унифицировать подход и сделать его независимым, мы сможем поделиться наработками в open source.
Полноценно проработать требования к отчётности на этапе подготовки договора было невозможным со стороны клиента, так как нужно было задействовать большое количество сотрудников и вовлечь разные подразделения. Также в это время в компании происходили структурные изменения и переход из одной системы в другую. То, о чем договорились бы в начале могло сильно измениться на этапе внедрения. Требования фиксировали на уровне: «возможность интеграции с внешними системами построения отчётности» и «возможность разработки пользовательских отчётов». Цель была такая: дать клиенту максимально эффективное решение исходя из его возможностей.
BI уже заточена под бизнес-показатели и его использование, на наш взгляд, было правильным решением. Иначе нам пришлось бы проводить большую работу по дублированию и адаптации этих данных в нашей системе — это не только наши ресурсы и время, но и большой объём работы со стороны клиента.
Так или иначе, базовые отчёты присутствуют в системе из коробки и позволяют решать практически все задачи для анализа работы КЦ. Пользовательские или кастомизированные отчёты позволяют привести к «знакомому виду» работу с отчётами в системе для клиента.
Спасибо большое за отклик — особенно ценно услышать мнение от коллеги с похожим опытом из другой области.
С джунами действительно важно удерживать баланс: мягкость помогает выстроить доверие, но если ошибки повторяются или нарушаются договоренности — я стараюсь говорить строже, но при этом сохранять открытый диалог.
Спасибо, что подсветили тему развития — очень важная и точно достойна отдельного разговора.
Спасибо за интерес к статье и нашей команде :) Можешь отправить резюме на job@naumen.ru — мы сохраним твои контакты и свяжемся, как только появится подходящая вакансия.
Спасибо за вопрос! Это была задача от заказчика по ручному анализу и очистке входящих данных в Excel. Тогда автоматизировать подобные процессы не получалось, поэтому задача относилась к зоне ответственности бизнеса — нужно было хорошо разбираться в специфике данных в их сфере. Мне же нужно было работать уже с актуальными данными.
Оба подхода обладают своими плюсами и минусами, серебряной пули, к сожалению, не существует. EAV использовался в проектном решении этой задачи, но таблица разрастается довольно быстро, и это может начать создавать проблемы производительности.
Что касается JSONB, то под капотом в случае с Postgres используется именно он — как более эффективный.
Привет! Спасибо, что высказал интересную мысль :) Мы всегда открыты к новым идеям, так что ты можешь написать нам в Telegram @naumen_connect, сможем подробнее обсудить формат, который тебе кажется перспективным.
Добрый день! Конечно, посчитать точно возможности нет, всегда есть приближенные расчеты.
Мы считаем, что повлияли именно изменения в продукте, так как «соседний» продукт для внутренней поддержки не вырос настолько же в тех же условиях рынка, когда началось импортозамещение. При этом исторически видели, что оба продукта примерно одинаково реагировали на волнения на рынке.
Я не встречал методик по определению уровня неопределенности. Существуют методы оценки риска, да. Но это другое. Суть mindmap, о котором идет речь в статье (можно посмотреть здесь: https://miro.com/app/board/uXjVNEOGewU=/), чтобы иметь инструмент для определения составляющих (аспектов), по которым мы, возможно, не учли какие-то требования. И далее, что делать, чтобы выявить и формализовать эти требования.
Проблема в статье рассматривается не с точки зрения менеджмента, а с точки зрения результативности команды. Конечно, это более актуально, когда формат договора предполагает обоюдную ответственность для заказчика и исполнителя, как, например, в fixed price & fixed scope. А еще более значимо во внутренней разработке.
Оценить рамки неопределенности как раз и помогает mindmap. Чтобы было понятнее, вот ссылка: https://miro.com/app/board/uXjVNEOGewU=/. Чем раньше с его помощью получится понять, что есть «слепые зоны», тем лучше для всех.
Да, верно, изначально в коде этой строки не было, видимо, при публикации что-то слетело. Спасибо за внимательность, поправили!
Если кратко, то: первое — наши хорошо отлаженные процессы позволяют проводить подобные обновления, второе — как отметил в статье, каждое обновление приносит с собой и улучшение языка, и повышение безопасности и перформанса продукта из коробки.
В финальной части доклада на ютубе более подробно рассказал, почему полезно обновление.
Клиентоориентированность — общая тенденция. Сейчас она применяется почти везде. В проектном подходе мы ориентируемся на конкретного клиента, для которого реализуем проект. А в продуктовом — на большинство клиентов, имеющих схожие потребности.
Процессный подход относится к другой категории. То есть его некорректно сравнивать или противопоставлять продуктовому подходу, о котором говорим в статье.
Когда собеседник не знает/не понимает конечную цель или не может ее сформулировать, он отвечает простыми и понятными ему вещами — рутинными действиями. Я это называю «Я работаю, чтобы делать свою работу».
Для того, чтобы копнуть глубже, использую метод «5 почему». Приведу пример из жизни, который рассказывал своим коллегам:
— Я хочу купить машину.
— Зачем?
— Чтобы ездить.
— Куда ты собираешься на ней ездить?
— Я хочу ездить на ней на работу.
— Ты можешь добираться на автобусе или на метро, это быстрее и без пробок. Для чего машина?
— Утром я хочу выезжать пораньше, чтобы успевать отвозить детей в детский сад, который находится на другом конце города. Потом добираться до офиса. После работы забирать детей из детского сада и возвращаться пораньше, чтобы успеть к ужину, который приготовила жена, после провести время с ней. А еще вспомнил, что хочу иногда ездить на базу отдыха за городом и не быть привязанным к расписанию электричек.
В этом примере мы натыкаемся на умение формулировать цель действия — покупки машины. Мы получили ответ «действие». Затем задали второй уточняющий вопрос и все равно получили ответ в виде действия. Лишь на третьем вопросе, копнув глубже, мы получили развернутый ответ и узнали те цели, которые преследует собеседник.
В проектах автоматизации мы натыкаемся на аналогичные случаи. Например, заказчик просит сделать в задаче даты планового и фактического выполнения. Его мотивация на поверхности — хочу видеть, какие сотрудники вовремя выполняют задачи. Если начать копать зачем, почему, когда — мы выясним: что он хочет каждый день видеть, какие сотрудники не укладываются в срок и по каким задачам. В ходе диалога мы понимаем, что ему нужна не просто дата, а еще и ежедневный удобный отчет. Пользователь не знал, что мы можем быстро настроить ему выгрузку, поэтому опирался на свой прошлый опыт — визуально бы сравнивал в экселе.
Решили выделить роль администратора из-за большой нагрузки на РП. В ответственность РП входит все вами перечисленное.
Мы ведем как записи встреч, если это возможно, так и протоколы, которые чаще пишут администраторы. В протоколах фиксируем, какие вопросы обсуждали и какие решения приняли. Поэтому нить проекта РП не упускает. К тому же, РП сам может зафиксировать важные для себя моменты.
Чтобы лучше понять разницу между процессным, проектным и продуктовым подходом, можно познакомиться со «стоматологической» аналогией.
Мы не оцениваем проектный и продуктовый подходы с точки зрения плохой или хороший —каждый из них применим в разных ситуациях. Для закрытия уникальной потребности лучше всего подойдет проект. А для решения типовых задач, повторяющихся у разных заказчиков, оптимален продукт
Считать ли типовые проекты продуктом? Это зависит от подхода, применяемого при реализации этих типовых проектов. Если каждый раз они выполняются «с нуля», без использования предыдущего опыта, то продуктом это назвать сложно. Если же есть типовые решения, которые применяются из раза в раз при совпадении исходных условий, то это уже ближе к продукту. А если эти типовые решения не просто применяются, но и анализируется опыт их использования, оптимизируется их функционал на основе этого анализа, то смело можем говорить о продуктовом решении.
Спасибо за комментарий!
Группа администрирования работает не только на проектах внедрения, а занимается отчетами, учетом лицензий, организацией обучения клиентов, организацией рабочего пространства для сотрудников подразделения и т.д. Также в практике два направления: продуктовое и центр внедрения. Группа администрирования работает на оба: например, тот же технический писатель занимается как проектной документацией, так и документацией для продуктов.
Если бы РП был прямым руководителем этой группы, на него легла бы дополнительная нагрузка — в виде распределения и контроля всех этих задач. Сейчас это делает Света.
Добрый день!
Света управляет командой из двух человек, поэтому, помимо задач администратора, готовит отчёты и распределяет активности внутри своей группы. В команде Светы есть технический писатель и ещё один администратор — так как проектов в работе много, один администратор бы не справился :) Поэтому было решено создать отдельную команду, которая помогает бизнесу.
Добрый день! Продукт построен на основе платформы Naumen SMP, над которой работает большая команда в компании. Так как платформа low-code, то небольшие автоматизации пишут все продуктовые аналитики. А наибольших успехов достиг Андрей :)
Добрый день! Это неотчуждаемый от особенностей нашей системы механизм, так как много логики завязано на тонкости нашей платформы. Возможно, в будущем, если у нас получится унифицировать подход и сделать его независимым, мы сможем поделиться наработками в open source.
Полноценно проработать требования к отчётности на этапе подготовки договора было невозможным со стороны клиента, так как нужно было задействовать большое количество сотрудников и вовлечь разные подразделения. Также в это время в компании происходили структурные изменения и переход из одной системы в другую. То, о чем договорились бы в начале могло сильно измениться на этапе внедрения. Требования фиксировали на уровне: «возможность интеграции с внешними системами построения отчётности» и «возможность разработки пользовательских отчётов». Цель была такая: дать клиенту максимально эффективное решение исходя из его возможностей.
BI уже заточена под бизнес-показатели и его использование, на наш взгляд, было правильным решением. Иначе нам пришлось бы проводить большую работу по дублированию и адаптации этих данных в нашей системе — это не только наши ресурсы и время, но и большой объём работы со стороны клиента.
Так или иначе, базовые отчёты присутствуют в системе из коробки и позволяют решать практически все задачи для анализа работы КЦ. Пользовательские или кастомизированные отчёты позволяют привести к «знакомому виду» работу с отчётами в системе для клиента.