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