У меня такая проблема была где-то на 3ем году в компании. Я отлично знала продукт, и мой руководитель посылал всех ко мне, и я уже была тем самым "бутылочным горлышком".
Наверное, не хватило примера. У меня была такая проблема: сотруднику (аналитику) сказали написать постановку на новую карточку. И сотрудник приходит ко мне с вопросами: а где постановка, с которой брать пример; а нужна ли форма редактирования и форма просмотра отдельно; а какие там поля должны быть; а, я не знаю, а кто знает, к кому ему пойти тогда? А есть материалы по тематике создаваемой карточки? Итдитп.
Причем если бы сотрудник потратил реально 5 минут, сделав запрос к конфлюенсу, часть вопросов бы снялось.
Или были ситуации, когда сотруднику Заказчик назначал делать макеты, сотрудник вообще не думал в запале работы, должен ли это он делать, должен ли он вообще уточнить у РП, должен ли он делать или нет, есть ли у нас дизайнер, например. И на выходе получалось плохо (не специализация аналитика) и Заказчик просил переделать и доделать - а мы вообще не должны были соглашаться. Проблема бы просто решилась, если бы сотрудник себя спросил - а мое ли это?
Про обучение сотрудников. Смешно, но мы много раз делали, но до тех пор, пока один "кассир" не отказывался отвечать на вопросы, никто не чесался вспомнить, чему их учили.
С должностными инструкциями согласна, в идеале это решит несколько проблем. У нас не ИТ контора, с ИТ подразделением, и чистой аналитики нет, есть люди с разноплановыми проектами, которых я, как руководитель и подбираю под их не только аналитические навыки. Пробовали написать инструкции, не пошло. Для кого-то это будет решением.
Мне кажется, вас покоробил тон статьи больше, чем что-то еще. Дружеская атмосфера и чувство локтя прекрасно до тех пор, пока более ленивый сотрудник не смекнет, что проще ходить со своей проблемой ко всем остальным. Или вы окажетесь тем человеком, к которому как к кассе в макдональдсе ходят все подряд, не соизволя даже банально воспользоваться гуглом (этим "кассиром" была я сама очень долго). И атмосфера в коллективе тоже была хорошая и все в этом духе, о чем вы пишете. Но никто не рос и не думал растить других сотрудников. У нас же коллективный дух.
Так что для меня все в статье - это база, о которой стоит помнить, когда сталкиваешься с проблемой. Что есть не только выход пойти спросить, а что ты,вообще то, можешь сам что-то сделать с этим.
Сложно явно приводить примеры, не затрагивая специфику компании, продукта или проекта, заказчиков. В общих случаях так и будет, а конкретно в каждом случае я бы применяла здравый смысл ) к сожалению, по моему опыту, даже его обычно не бывает при принятии решения о приоритете. Поэтому и получается либо совсем базовые принципы, либо специфика.
О высококвалифицированных сотрудниках на позициях. HR приходится выбирать из того, что есть на рынке, а не искать идеальных кандидатов. У вас все с этим хорошо?
У нас так было тоже в одном большом проекте! Кроме "почитать документацию" давали доступ к видео, где черт ногу сломит, а человек, у которого было все в голове, был один. Долго думали, что с этим делать в условиях такого легаси, и придумали только составить порядок видео, который нужно смотреть, а не все подряд.
Вы так и не придумали более дружественного варианта погружения?
Это любимая штука менеджеров, руководителей проекта и всех, кто отвечает за трудочасы команды. Типа мы оптимизировали, часы не понратили, "мемо" сделали (файл выложили). Только потом окажется, что кто-то не так понял договоренности, и часов после исправлений потратится больше.
Классно, когда можно сразу, но у меня никогда не выходило. Приходишь с встречи, а у разработчиков встала работа, и нужно всем ответить на их вопросы, чтоб опять могли работать. Поэтому я и говорю про сутки.
С диктофоном часто бывают накладки - если психологически запись онлайн встречи заказчик еще может переварить, то диктофон - почему-то нет.
Мы брали так: сначала взяли факт по трудозатратам, затем вывели формулу оценок через коэффициент, а затем полтора года оценивали требования по этой модели и вышли на такие же фактические трудозатраты. Явно каждое требование мы не оценивали с т.зр. прогноз/факт. Нам, на самом деле, было важно разработать такую модель, чтобы уменьшить трудозатраты по пресейлам - они являлись дырой в бюджете (вся работа по оценке требований до контракта) и нам было важно как более точно с наименьшим временем их оценить.
Да, тут важно, что это был продукт, но я решила опубликовать наш опыт, так как, когда я искала хоть какие-то варианты оценок требований не в стори-поинтах, информации не было.
Аналитики как раз и давали оценку на разработку, консультируясь с архитектором, который и отвечает за разработчиков. Т.к. в нашем случае добиться быстрого и вменяемого ответа от разработчиков на вопрос: "за сколько сделаешь" было нереально. QA всегда было долей от общего числа часов. Т.е. именно в нашем случае статистически +- мы всегда знали, сколько займет тестирование. Были некоторые отклонения, где, действительно, отдельно добавляли часов на тестирование, но в среднем по департаменту и всем ее проектам за год тестирование выводилось формулой.
Нам не важно было в рамках одной конкретной задачи дать точные оценки, важна была скорость оценок всех требований по пресейлам и экономия времени на входе. А также среднее число "по больнице" в год уравнивало все погрешности каждого конкретного требования в каждом конкретном проекте.
Да, я сразу в начале статьи описала, что у нас была за платформа и запросы. И к нам тоже приходили такие ТЗ на 150страниц, но за два часа можно было его прочитать и сказать - это наше/не наше, будем ли мы тратить приличное количество наших часов на этот пресейл, какой шанс, что его выиграем.
Т.к. компания была не гигантская, мы сразу договорились с руководством, что имеем право "завернуть" запрос и отказаться еще в самом начале.
Тут дело даже не в двух часах или нет, в зависимости от бизнеса планка может быть любой, но мы создали принципы, которые позволяют оценивать входящий запрос за это время
А как понять, что человек талантлив И готов давать результаты? У нас были кейсы, когда по началу у нового человека были и идеи, и запал предлагать что-то новое, но дальше идей ничего не уходило, реализовать (т.е. принести пользу для компании) человек не мог.
Мне самой больше всего нравятся обучаемые "середнячки" и нормально поставленные задачи на развитие. Но очень многие приходят в компании, или считают себя этими самыми талантами, и хотят какого-то особого отношения к себе. И мои требования к ним "просто сделать то, что нужно" выливается в переработки и отсутствие нормальной обратной связи. Если бы пришли и сказали "я не понял, повтори, что ты от меня ожидаешь получить по задаче", проблем было бы меньше, и нарушения ворк-лайф баланса тоже. Но все ж Звезды, вот и хромает и бизнес результаты, и баланс.
Поэтому тут я пишу статьи про софт скиллы, чтоб было не только про качество работы сотрудника, но и сотрудник не страдал и знал, как выйти из ситуаций))
Мне кажется, у вас очень противоречивые точки зрения - с одной стороны, вы пишете, что хорошо коммуницируете, а с другой, что вам не понравится общаться с людьми не айти сферы. Они не глупые, просто сфера их бизнеса лежит не в сфере айти, и это главная задача аналитика - помочь бизнесу зарабатывать деньги через, например, создание интернет-магазина.
По мне, аналитики - это лишь инструмент трансляции проблем бизнеса на язык разработчиков. Мне лично всегда было интересно погружаться в новый бизнес, узнавать что-то новое и применять в работе. Можно совершенно точно не говорить с ними на языке айти, а говорить на обычном русском, так как это вам надо выяснить у них, что им нужно, а не им учиться новым терминам.
Это отличная идея в формате больших компаний и супер-кадров-талантов, которые хочется и нужно удерживать. Но в небольших компаниях надо не забывать о самом важном - эффективности работы сотрудника. Сначала становись ценным кадром, потом заботься о ворк-лайф балансе на работе.
У меня такая проблема была где-то на 3ем году в компании. Я отлично знала продукт, и мой руководитель посылал всех ко мне, и я уже была тем самым "бутылочным горлышком".
Спасибо за рек, посмотрю
Наверное, не хватило примера. У меня была такая проблема: сотруднику (аналитику) сказали написать постановку на новую карточку. И сотрудник приходит ко мне с вопросами: а где постановка, с которой брать пример; а нужна ли форма редактирования и форма просмотра отдельно; а какие там поля должны быть; а, я не знаю, а кто знает, к кому ему пойти тогда? А есть материалы по тематике создаваемой карточки? Итдитп.
Причем если бы сотрудник потратил реально 5 минут, сделав запрос к конфлюенсу, часть вопросов бы снялось.
Или были ситуации, когда сотруднику Заказчик назначал делать макеты, сотрудник вообще не думал в запале работы, должен ли это он делать, должен ли он вообще уточнить у РП, должен ли он делать или нет, есть ли у нас дизайнер, например. И на выходе получалось плохо (не специализация аналитика) и Заказчик просил переделать и доделать - а мы вообще не должны были соглашаться. Проблема бы просто решилась, если бы сотрудник себя спросил - а мое ли это?
Про обучение сотрудников. Смешно, но мы много раз делали, но до тех пор, пока один "кассир" не отказывался отвечать на вопросы, никто не чесался вспомнить, чему их учили.
С должностными инструкциями согласна, в идеале это решит несколько проблем. У нас не ИТ контора, с ИТ подразделением, и чистой аналитики нет, есть люди с разноплановыми проектами, которых я, как руководитель и подбираю под их не только аналитические навыки. Пробовали написать инструкции, не пошло. Для кого-то это будет решением.
Мне кажется, вас покоробил тон статьи больше, чем что-то еще. Дружеская атмосфера и чувство локтя прекрасно до тех пор, пока более ленивый сотрудник не смекнет, что проще ходить со своей проблемой ко всем остальным. Или вы окажетесь тем человеком, к которому как к кассе в макдональдсе ходят все подряд, не соизволя даже банально воспользоваться гуглом (этим "кассиром" была я сама очень долго). И атмосфера в коллективе тоже была хорошая и все в этом духе, о чем вы пишете. Но никто не рос и не думал растить других сотрудников. У нас же коллективный дух.
Так что для меня все в статье - это база, о которой стоит помнить, когда сталкиваешься с проблемой. Что есть не только выход пойти спросить, а что ты,вообще то, можешь сам что-то сделать с этим.
Сложно явно приводить примеры, не затрагивая специфику компании, продукта или проекта, заказчиков. В общих случаях так и будет, а конкретно в каждом случае я бы применяла здравый смысл ) к сожалению, по моему опыту, даже его обычно не бывает при принятии решения о приоритете. Поэтому и получается либо совсем базовые принципы, либо специфика.
О высококвалифицированных сотрудниках на позициях. HR приходится выбирать из того, что есть на рынке, а не искать идеальных кандидатов. У вас все с этим хорошо?
Да, в последнее время в условиях кадрового голода именно такое и есть. Очень многие роли пересекаются, особенно в небольших компаниях.
У нас так было тоже в одном большом проекте! Кроме "почитать документацию" давали доступ к видео, где черт ногу сломит, а человек, у которого было все в голове, был один. Долго думали, что с этим делать в условиях такого легаси, и придумали только составить порядок видео, который нужно смотреть, а не все подряд.
Вы так и не придумали более дружественного варианта погружения?
Это любимая штука менеджеров, руководителей проекта и всех, кто отвечает за трудочасы команды. Типа мы оптимизировали, часы не понратили, "мемо" сделали (файл выложили). Только потом окажется, что кто-то не так понял договоренности, и часов после исправлений потратится больше.
Я пару раз так делала - чем более техническая, не бизнесовая встречи, тем хуже эта штука работает :(
Классно, когда можно сразу, но у меня никогда не выходило. Приходишь с встречи, а у разработчиков встала работа, и нужно всем ответить на их вопросы, чтоб опять могли работать. Поэтому я и говорю про сутки.
С диктофоном часто бывают накладки - если психологически запись онлайн встречи заказчик еще может переварить, то диктофон - почему-то нет.
Хорошо - всмысле, что Заказчикам не все равно) Но бывают такие встречи, что мы задаем вопрос, как лучше сделать то или иное, и вот тут начинаются идеи
Спасибо, хороший материал!
Есть такая штука, как "разрыв шаблона", очень понятно на примере:
Оппонент: "у вас очень дорогая система"
Вы: "Сейчас такая стоимость, а через неделю стоимость будет повышена на 30%".
После такого обычно собеседник уходит в состояние транса, и все, можно говорить что угодно )
Мы брали так: сначала взяли факт по трудозатратам, затем вывели формулу оценок через коэффициент, а затем полтора года оценивали требования по этой модели и вышли на такие же фактические трудозатраты. Явно каждое требование мы не оценивали с т.зр. прогноз/факт. Нам, на самом деле, было важно разработать такую модель, чтобы уменьшить трудозатраты по пресейлам - они являлись дырой в бюджете (вся работа по оценке требований до контракта) и нам было важно как более точно с наименьшим временем их оценить.
Да, тут важно, что это был продукт, но я решила опубликовать наш опыт, так как, когда я искала хоть какие-то варианты оценок требований не в стори-поинтах, информации не было.
Аналитики как раз и давали оценку на разработку, консультируясь с архитектором, который и отвечает за разработчиков. Т.к. в нашем случае добиться быстрого и вменяемого ответа от разработчиков на вопрос: "за сколько сделаешь" было нереально. QA всегда было долей от общего числа часов. Т.е. именно в нашем случае статистически +- мы всегда знали, сколько займет тестирование. Были некоторые отклонения, где, действительно, отдельно добавляли часов на тестирование, но в среднем по департаменту и всем ее проектам за год тестирование выводилось формулой.
Нам не важно было в рамках одной конкретной задачи дать точные оценки, важна была скорость оценок всех требований по пресейлам и экономия времени на входе. А также среднее число "по больнице" в год уравнивало все погрешности каждого конкретного требования в каждом конкретном проекте.
Да, я сразу в начале статьи описала, что у нас была за платформа и запросы. И к нам тоже приходили такие ТЗ на 150страниц, но за два часа можно было его прочитать и сказать - это наше/не наше, будем ли мы тратить приличное количество наших часов на этот пресейл, какой шанс, что его выиграем.
Т.к. компания была не гигантская, мы сразу договорились с руководством, что имеем право "завернуть" запрос и отказаться еще в самом начале.
Тут дело даже не в двух часах или нет, в зависимости от бизнеса планка может быть любой, но мы создали принципы, которые позволяют оценивать входящий запрос за это время
А как понять, что человек талантлив И готов давать результаты? У нас были кейсы, когда по началу у нового человека были и идеи, и запал предлагать что-то новое, но дальше идей ничего не уходило, реализовать (т.е. принести пользу для компании) человек не мог.
Мне самой больше всего нравятся обучаемые "середнячки" и нормально поставленные задачи на развитие. Но очень многие приходят в компании, или считают себя этими самыми талантами, и хотят какого-то особого отношения к себе. И мои требования к ним "просто сделать то, что нужно" выливается в переработки и отсутствие нормальной обратной связи. Если бы пришли и сказали "я не понял, повтори, что ты от меня ожидаешь получить по задаче", проблем было бы меньше, и нарушения ворк-лайф баланса тоже. Но все ж Звезды, вот и хромает и бизнес результаты, и баланс.
Поэтому тут я пишу статьи про софт скиллы, чтоб было не только про качество работы сотрудника, но и сотрудник не страдал и знал, как выйти из ситуаций))
Мне кажется, у вас очень противоречивые точки зрения - с одной стороны, вы пишете, что хорошо коммуницируете, а с другой, что вам не понравится общаться с людьми не айти сферы. Они не глупые, просто сфера их бизнеса лежит не в сфере айти, и это главная задача аналитика - помочь бизнесу зарабатывать деньги через, например, создание интернет-магазина.
По мне, аналитики - это лишь инструмент трансляции проблем бизнеса на язык разработчиков. Мне лично всегда было интересно погружаться в новый бизнес, узнавать что-то новое и применять в работе. Можно совершенно точно не говорить с ними на языке айти, а говорить на обычном русском, так как это вам надо выяснить у них, что им нужно, а не им учиться новым терминам.
У меня есть пост про это ("Бесят идиоты-заказчики. Что делать?") на я.дзене https://dzen.ru/a/ZdRnyvuY-mqVQNun
Это отличная идея в формате больших компаний и супер-кадров-талантов, которые хочется и нужно удерживать. Но в небольших компаниях надо не забывать о самом важном - эффективности работы сотрудника. Сначала становись ценным кадром, потом заботься о ворк-лайф балансе на работе.