Комментарии 208
Красный текст я бы не использовал. Это теоретически проканает пару раз, потом замыливается, а автор таких писем получит заслуженный приз "долбак месяца". Поймите, вам может и срочно (а скорее всего нет), а им - точно нет, так зачем вы КРИЧИТЕ? Вам же еще там работать, правда?
-------------------------
Пересылка скорее всего возникает от двух причин:
вы пишете не тому
задача в целом комплексная и никто не подписывался менеджить ее управление за вас (или кого-то другого)
В первом случае все просто. Во-втором - возможно именно вы тот, кто должен всех организовать. Тогда письма в стиле "сделайте мне все" заслужанно занимают свое место ближе к ТОП "так делать не надо". Но это догадки
-------------------
Некоторые пункты вроде назначения ответственных настолько базовые, что вызывают догадки, что не все так хорошо в вашем королевстве. Ну правда, если к задаче нужно приписать ответственного и срокк и это лайф хак - тут надо начинать лечение с основ.
----------------------
Добавление руководителя - это прием, которые также работает некоторое время, потом перестает. Так как руководители - люди занятые, то ситуация, когда им кто-то много пишет (или ставит в копию) по вопросу, которым им на фиг не упал вызывает неодолимое желание позвонить и попросить больше так не делать.
-----------------------
Также, вы не уточняете сроки (либо у вашей организации большие проблемы). Это в целом неправильно. Задача с момента того, как она стала таковой, имеет исполнителя и срок, который он подтвердил. Если вы просто просите срок, а я (ваш конкурент, уже согласовал, что моя другая задача будет 14го до 12) - 99% что мою сделают, а вашу нет.
Основное:
Вы должны понимать срочность вопроса. Это это не критично - не долбите. Оно вам точно не пригодится
Вы должны понимать мотивацию тех, то делает задачу. Не, конечно банально все типа получают ЗП и должны по первому зову вам все делать ... но нет. У людей может быть 100500 причин, почему они делают что-то другое
Вы должны писать "комфортные" письма. Условно у вас есть задача, вы ей живете, а для кого-то - это одна из 20. Тут прилетает письмо, о чем, кто это, почему "на вчера"?
По хорошему стоит уточнить:
если были договоренности, почему вы просите именно этот срок - сошлитесь на них, либо форвард. Если у вас договоренностей нет - вы лузер и задачи нет :)
учтоните, есть ли у исполнителя проблемы/вопросы/препятствия. Они реально могут быть, но лучше уточнить явно. Как ни странно, это триггерит более детальные ответы
если срок по какой-то причине не будет выдержан, можно указать, почему это плохо (но не для вас лично - на вас всем насрать по определению)
если дело зашло слишком далеко (нет реакции, ответ "иди на фиг, мальчик"), стоит тогда уже с этим письмо идти к начальству (это называется эскалация)
Либо можно и дальше долбить всех красным цветом
Верно
Гори в аду
Гори в аду
Гори в аду
Это как вообще? кто и или что кого должно ограничить?
А зачем протокол без ответственных? Это не просто стандартная практика, а это единственное осмысленное действие в протоколе
Очень сомневаюсь что от количества "пожалуйста" хоть что-то зависит
Игнорят письма, потому что людям есть чем заняться вместо ответов на тупые вопросы.
Посоветую бросить работы в ИТ, поискать гденить в другом месте.
Ваш праведный гнев можно понять. Но он направлен не на того человека. Аналитик действительно должен взаимодействовать с разработчиками. И разработчики должны взаимодействовать с аналитиком. Но у них на это нет времени. Потому, что разработчику не выделяют время на встречи, переписки и разговоры. Ему даже на непосредственно программирование выделяют времени в разы меньше, чем по-хорошему надо выделять. А уж если ещё закладывать время на митинги, переписки и созвоны, то надо сразу количество времени умножить на 10. Ну так должно было бы быть по-нормальному, но пришёл аджайло-скрам и всё опошлил.
Почему же?
Во-первых для начала наверное стоит прочитать Ильяхова про его правила деловой переписки.
Во-вторых если ты пишешь людям, а тебя игнорят, то это проблемы у тебя, а не у них. Если твоя работа заключается в общении с людьми, то твоя первая задача, чтобы они всегда были рады когда ты им звонишь и пишешь.
И самые лучшие способы добиться того чтобы люди были тебе не рады:
Звонить или кидать встречи без предупреждения или согласования
Писать письма крупным или красным шрифтом
Везде добавлять руководителя в переписку
Откровенный газлайтинг. Не надо оправдывать чужую лень и возвеличивать собственную значимость. Человек не рецепт салата хочет обсудить. Над общим делом все-таки работаете, а не в коллективе, где коллеги друг-другу крысы и только щелканье кнута надсмотрщика начальника приводит отдел в чувство.
Показалось (по некоторым момента) что статья про ту контору на кого я работаю. Но нет. Автора нет ни в реестре пользователей корппочты ни в официальном мессенджере.
Но вот например если кто-то вроде автора как в статье попробует со мной (я разработчик) - ну получит на все запросы ответ - "идите к PO и Scrum'у моим, у меня прямая инструкция что любые незапланированные задачи только через них"(такая инструкция реально есть просто обычно все сильно мягче).
При этом вполне себе нормально считается например для согласования протокола ПСИ - искать контакты согласующих в телеграме чтобы попросить(который официально запрещен к использованию и есть ж официальный корпмессенджер но вот только пользуются им ой не все(возможно потому что способа реально использовать с компа который бы у всех работал - нет), с корппочтой - кое кто ее вообще раз в несколько дней читает - спасибо "удобству", причем в рамках импортозамещения все стало только хуже)
Любой ответ, даже с переадресацией это уже ответ
Такой ответ будет в удобное мне время (а не "сразу"), искать контакт - сами будут, переписка по таким вопросам идет обычно...долго (разработчики обычно в копии поэтому и знаю).
При этом - если приходит например креш с метрики - я вероятно попрошу нашего тестировщика завести на меня дефект в этом спринте со ссылкой на метрику, и быстро поправлю. Хотя вообщем то - могу тоже тянуть...долго.
Если твоя работа заключается в общении с людьми, то твоя первая задача, чтобы они всегда были рады когда ты им звонишь и пишешь.
- что-то из серии "сама юбку надела".
Всегда радовать программистов - точно не задача аналитика. Может только корпоративного клоуна или бухгалтерши с конвертом с зарплатой.
В компании обычно есть правила, как быстро обязан отвечать на обращения коллег
>гори в аду
Кажется, кто-то не любит отвечать на почту))))
Ваши "гори в аду" как раз показывают, что это работает и вы будете неспособны это проигнорировать, особенно четвертый пункт, но ведь автор статьи дает советв не вам, а тому, кто с вами взаимодействует. В большой корпорации без некоторой доли работы локтями никак. И да, встреча с руководителем решает проблему с переадресацией.
Где-то это сработает, но стабильно генерируемый в контрагенте негатив может вызвать подсознательное желание в принципе поскорее закончить взаимодействие и подольше его не возобновлять.
"Извините, бэклог забит до 2025Q1. Давайте подождём и в следующем году вернёмся к вашему вопросу"
"Нет, архитектурно вам вообще не к нам надо стучаться."
Ответ есть ответ. Аналитику таких ответов тоже будет достаточно. Он их подошьёт в документацию и отправит на рассмотрение руководителю проекта. Дальше будет весело.
Понятно, что любой адекватный человек не мечтает о том, чтобы другим было с ним неприятно общаться. Но в конечном-то итоге если вы таким образом избегаете ответа по существу, то к вам все равно потом придут, но с вашим руководителем. И именно зная это вы скорее всего и не отмахнетесь.
Ну во-первых, руководитель тоже человек и ему тоже может не очень нравиться неприятный контрагент.
Во-вторых, ответ с отказом может быть и по существу. Просто при наличии вариантов "отказать, т.к. это самый очевидный вариант" или "поднапрячься и всё-таки придумать подходящее всем решение" сотрудник неосознанно может остановиться на первом, если ему хочется поскорее завершить общение. Не всегда далеко, но в долгой перспективе может набраться какой-то значимый процент.
Ответом по существу будет "отказать с объяснением, почему отказано", тогда и поход к руководителю, возможно, не нужен будет. Задача аналитика, который к вам пришел, - сделать так, чтобы вам выгоднее было выдать максимум информации, чтобы от вас отвязались. Ведь его работа - собирать и агрегировать инфу, и в особенности на ранних этапах профессионального развития ему важно с вас стрясти максимум информации, чтобы как нейросеть на ее объеме обучаться.
Руководитель, кстати, скорее встанет тут на сторону аналитика по той же причине, - ему проще выдать аналитику максимум инфы, чтобы не менеджерить общение с ним до бесконечности, и потом получить адекватные требования для подготовки задач в работу, потому что от аналитиков в первую очередь зависит качество требований.
Конечно же это не так. Если мне любой человек будет так писать, то я сразу же попрошу своего или его руководителя исключить этого человека из общения со мной.
это в принципе нормально - отказываться работать с тем, с кем ты не хочешь работать.
Конечно же, это так: маня-мирок с розовыми поняшками.
Это как? Есть аналитик или продает овнер по какому-то продукту. Он может быть один. Отказаться от общения с ним означает отказаться заниматься соответствующими проектами или заставлять кого-то быть буфером между вами. Зачастую отказаться можно только сменив проект.
Потом он придет к своему руководителю, его руководитель к вашему и даст по шапке за саботаж. Разве не так?
Скорее всего в том типе компании, которую описывает автор поста, после такой просьбы к руководителю вам предстоит еще общение с вашим руководителем на тему "а все ли у вас в порядке, а уверены ли вы, что без чрезмерного труда справляетесь с рабочими задачами" и потом, вероятно, также общение с сотрудником HR-отдела на ту же тему, возможно с "очной ставкой" с этим самым человеком, с которым вы отказались работать. Потому что конечно же для более-менее отлаженной организации отказываться с кем-либо работать не то чтобы ненормально, но вызывает большие напряжения у менеджмента, который начинает переживать, что не все отлажено. Причем ваш руководитель будет понимать, что за той же инфой аналитик придет к нему, если вы откажетесь с ним общаться, так что вашему руководителю будет гораздо удобнее наладить ваше взаимодействие с аналитиком.
Сними корону... Что за принцесса: "мне он не нравится, исключите его из моего общения". Человек вам не анекдоты рассказывает, а решает рабочие моменты. Даже если это джун зелёный, который обращается к вашему сеньерскому величеству, ему нужно помочь, вы оба работаете над одной целью и в одной лодке.
Вот это бомбануло. От экрана аж гарью повеяло. Я под впечатлением :)
Я не всегда переписываюсь так. Красной пастой, с руководителем в копиях и прочее. Это те самые тревожные кнопки, которые аналитик нажимает, когда вопрос срочный и от него зависит, например, ход и сроки нашей разработки.
Во-вторых если ты пишешь людям, а тебя игнорят, то это проблемы у тебя, а не у них. Если твоя работа заключается в общении с людьми, то твоя первая задача, чтобы они всегда были рады когда ты им звонишь и пишешь
Это вообще очень смешно было читать.
Зависит от аналитика.
Если это мой аналитик, то руководитель и красная паста не сильна нужна. Нам обоим.
Если это не мой аналитик, то я его пошлю (перешлю) к моему аналитику =)
Вас тут заминусили, поэтому дам комент в поддержку, люди не имеющие подобного опыта в принципе плохо представляют что это такое "работать с людьми" когда тебе от них что-то нужно, пока сам не попробуешь многое остаётся скрытым.
А должно быть грустно. Вы не осознаете проблему, которую создаете себе и другим.
Продолжайте в том же духе и скоро заметите как все «срочные вопросы», от которых что-то зависит, пойдут мимо вас.
Блин, рецепт джуна по общению с другими отделами другим джунам, когда страшно, неловко и во всём сомневаешься, особенно в себе. Конечно после этого перекос может пойти в обратную сторону - жать на коллег, орать красным и всё такое. Но в целом как рецепт начинающего начинающим - очень годно и структурированно. И цель общения выписана вроде нормально - сделать свою работу хорошо. Со временем всё устаканится у автора. Не воспринимайте персонально )
Протокол без ответственных - для фиксации договоренностей. Чтобы бить его распечаткой всех, кто решит запилить отдельный микросервис, или наоборот, добавить новую функциональность в легаси код, запланированный к уничтожению.
Красный текст я бы не использовал. Это теоретически проканает пару раз, потом замыливается
Я с некоторых пор приучил себя использовать три "серебряные пули": курсив, болд, и подчеркивание.
Прямо заметно, что мои послания стали читать, как минимум, внимательнее.
за подчёркивания в мире повального гипертекста вас наверняка частенько матерят — тыкаешь в «ссылку», а она не открывается ?♂️
Это что.... Бывает, в письме шрифт в цвет фона используют для выражения гнева и неголования, а потом пиьсмо открывается в режиме текст. И, там, подстава....
тыкаешь в «ссылку», а она не открывается
Гиперссылки обычно синие. Да и сложно предположить, что в фразе "ни в коем случае не устанавливайте релиз ХХХ, используйте релиз YYY" подчеркнутый кусок куда-то ведет :)
У меня в корпоративном аутлуке давно стоит красный шрифт по умолчанию для ответов. Только не тот алый красный, как в палитре, а специально подобранный не кричащий темно-красный. Никто не возмущается, привыкли, наверное. Зато удобно видеть где чья цитата.
У нас корпоративная политика запрещает использовать красный в письмах. Американская компания.
Боятся, что с красным цветом в письмах по организации распространится коммунизм.
Ну, можно ржать над "нутупыыми", но это кусочек более широкого набора правил, который помогает избегать неадеквата в рабочем общении, и при прочих равных я бы выбрал работодателя, который о таких вещах заботится. Не снежинка, не левак, просто вижу общую полезность в такой культуре, часто отсутствующей в российском бизнесе.
помогает избегать неадеквата в рабочем общении
Помогает маскировать неадеквата в рабочем общении. Запрет определённого цвета это борьба с симптомами, а не с болезнью.
А бордовый или розовый можно?
Обычно, по вопросам сроков лучше всех осведомлены менеджеры. Один менеджер - одна команда. Одна из задач менеджера - поддерживать прозрачность движения задач.
@barrybarry можете привести пару примеров, кому какой вопрос вы отправляли и не получали ответа? Возможно, проблема на поверхности :)
Ждать оперативного ответа на Email... Вы же прекрасно понимаете что email не работают если нужна оперативность. Идешь и пишешь коллеге в слак/телегу/любой мессенджер. Если совсем сложно, сразу ссылку на зум на 30 мин и вопрос решен. Зачем использовать устаревшие бюрократические инструменты? А потом удивления
Это явно не проблема джуниор-аналитика, вряд ли во всей компании принят слак или телега, а она принципиально пишет на почту. А к выводу про зум автор как раз и пришла
Вот об этом и написали, что это была проблема джуна-аналитика. Никто из команды не подсказал, как оперативно решать подобные ситуации.
Напрашивается вопрос, а все ли в порядке в команде самого джуна-аналитика?
Почему нормально его не адаптируют?
Обычно, в крупных компаниях уже действуют процессы адаптации. С коллегами по отрасли часто обсуждает процесс найма и инструменты/процессы адаптации новых коллег.
Из контекста похоже что под оперативностью подразумеваются дни. На мой взгляд если в компании принято общение через email, то сотрудники должны читать почту хотя бы 1-2 раза в день. Я лично жалею, что сейчас стали активней использовать чаты вместо почты. В почте письма были содержательней, со всеми нужными по конкретному письму адресатами и не такими назойливыми. А чат должен идти в дополнение по срочным вопросам и обсуждениям.
Чаты использую для оперативных коммуникаций - постоянно и очень много. Почта, Confluence, Jira - в основном, для фиксации договоренностей (сроки, функционал, да любые проектные и продуктовые артефакты, которые важны).
В переписке всегда указываю персоналии "с кем и о чем" договорились, иначе эти письма будут "на деревню дедушке".
Иногда, если вопрос игнорируется, то могу эскалировать выше, но, как правило, достаточно упомянуть в переписке "если по данному вопросу не будет возражений до такого-то числа и такого-то времени, то считаем, что все согласны с предлагаемым решением". Даже полные дебилы и лентяи начинают понимать, что игнор потом выйдет боком - отвечают.
Со временем культура использования коммуникаций вырастает. Сейчас большинство вопросов решаем через чаты между собой. Почта - только для межкомандных и внешних взаимодействий, что серьезно может влиять на сроки/архитектуру/стоимость.
Всё относительно. Автор пишет, что ответа временами ждать неделями. На таком масштабе почта точно справляется с запасом. Сутки - вполне разумный и оперативный срок для многих вопросов и многих контор. По меньшей мере, для не-основных задач. Я зачастую на почту отвечаю куда быстрее, чем в мессенджеры, особенно если ответ нужен развёрнутый. И считаю, что время, которое можно с чистой совестью провести "в зоне", должно всячески охраняться. Корпоративная культура, в которой по любому чиху все бегают друг к другу каждые 15 минут, приводит только к суете и выгоранию. Бюрократии, в которой на всякий запрос нужны два десятка виз и два месяца рассмотрения, конечно, тоже быть не должно. Всего в меру.
Но почта вполне всё ещё может быть эффективным рабочим инструментом, и она таки удобнее, если (под)задач много, а сверхсрочности по ним нет.
не, ну так-то все правильно в общем за исключением красивости в виде красного цвета.
но забыты главные слова: быстро, падлы! :)
«Подскажите по срокам смежников»
Это не вопрос. Я на такое если и отвечу, то что-то вроде «что именно по срокам надо подсказать».
Читая это я понимаю что вопрошающий не понимает сути вопроса. Скорее всего транслирует что-то, полученное от кого-то, а то что я отвечу будет так же, без анализа, передано куда-то ещё.
Конкретизируйте вопрос. Задайте несколько четких вопросов, на которые будет просто ответить без игр в «отгадай что имел ввиду автор».
Дык, сроки это вообще больная тема, особенно в разработке. Потому что спрашивающий ожидает чёткую цифру (чтобы потом тебя ей долбить), а там всё намного сложнее и каждый раз это объяснять новым людям очень надоедает.
Потому что это, блин, IT-разработка.
Настроить уже готовый функционал - минутное дело. И часто он уже есть в каком-то виде.
А если его нет или попробовал, но он не подходит? Тогда нужно посмотреть, что есть из готовых библиотек или подобного функционала. Это уже часы/дни.
А если нормальных готовых библиотек нет или попробовал и не подходят? Тогда нужно свой код писать, а это уже дни/недели/месяцы.
И как это всё обозначить одной цифрой ещё до начала работ? Да никак. Да и после начала, на любом этапе вплоть до завершения, никогда нет 100% гарантии что ты "уже почти сделал" и твой подход не тупиковый и всё не придётся переделывать с нуля. Поэтому на такие вопросы и не любят отвечать, ни разработчики менеджерам, ни одни менеджеры другим.
Есть задачи, по которым все вами выше сказанное справедливо, а есть те, по которым сроки очевидны или даже приняты как обязательства. Если вы о задаче первого типа напишете то, что написали выше, то вполне "подскажете по срокам", вы дадите свою оценку неопределенности для задачи и покажете, каков текущий этап работы над ней.
"Мутная" тема, т.к. ею не занимаются серьезно, а берут, зачастую, сроки "с потолка". Или после заявленных сроков менеджер делит на два, а то и больше.
Если новая тема, то нужно выделять время на исследование и эти исследования тоже контролировать. Т.е. не абстрактные "полгода", а, например:
3 дня на исследование вопроса: как народ решает подобные задачи, какие библиотеки и какие отзывы. Представление отчета по исследованиям с презентацией и обсуждением.
По результатам обсуждений выбираем направление, или несколько, и для них точно также выделяем: дизайн, разработка, тестирование, отладка, выпуск. И их оцениваем. Т.е. ничего сверестественного и нормально все оценивается и слона едим частями.
Принято считать, что ИТ молодая отрасль и этот миф взращивается нерадивыми менеджерами, которые привыкли в мутной воде удить рыбу.
И как это всё обозначить одной цифрой ещё до начала работ? Да никак.
Не совсем верно. Нужно разбить задачу на этапы. И отвечать: "Мы занимаемся исследованием/подбором/проектированием решения проблемы/задачи, займёт это N дней, после чего мы озвучим время, требующееся для внедрения выбранного решения."
Я бы понял, если бы такие телеги задвигал руководитель какого-то глобального и архисложного проекта, например, атомного проекта, или лунной программы, ну или если из современного - условного нейралинка. Короче, когда десятки или сотни тысяч людей создают что-то очень сложное и доселе неведомое, зачастую не вполне понятное даже фундаментально. И то, в каждом из этих проектов был четкий план со сроками.
Но когда разработчик рядового программного продукта заявляет, что его задача слишком сложна для того, чтобы оценить сроки выполнения...Хочется спросить - а как вы вообще работаете? Что вы заказчику говорите, откуда берете сроки, прописываемые в договоре? Как вы задачи подчиненным раздаете, откуда берете дедлайны по этим задачам? Как контролируете прогресс выполнения? А если в проекте задействуются смежные подразделения или подрядчики, как вы распределяете ответственность?
При том же я ни разу не видел, чтобы сроки требовали сразу же при постановке задачи. Всегда дают на это время, соразмерное сложности задачи. В крупных проектах этап планирования чаще всего вообще выделяется в отдельно оплачиваемый этап работ. Более того - заказчик принимает решение и заключает договор на основную часть работ на основании разработанного плана.
Одно из отличий профессионала от дилетанта - умение планировать свою работу, в том числе и по времени. Подход "главное ввязаться, а там разберемся" - это подход дилетанта.
При том же я ни разу не видел, чтобы сроки требовали сразу же при постановке задачи.
Значит, вы ни разу не работали напрямую с заказчиком - мелким/средним бизнесом и частниками. Потому что срок идёт в прямой зависимости от стоимости проекта. А стоимость им нужна ещё до заключения договора. Той же кафешке за 5 т.р. автоматическая умная предлагалка соуса на сайте не помешает, а за 100 т.р. - не, дорого.
И нет, у вас не получится уломать их заплатить 10 т.р. "просто так", за то что разработчик денёк посмотрит, поковыряет их сайт и подумает. Им нужен ощутимый результат. Сделаешь за 5 т.р. - берись, нет - проваливай. Но говори сразу, вотпрямщас.
Одно из отличий профессионала от дилетанта - умение планировать свою работу, в том числе и по времени.
Как раз таки одно из отличий профессионала от дилетанта в том, что он осознаёт все потенциальные подводные камни и их влияние на сроки. И то, что срок - это не цифра, а вероятностная шкала.
Это у дилетанта - "будем считать, что одна кнопка это один час работы. 80 кнопок = 80 часов = 10 дней".
А в реальности не может быть у разработки фичи чёткого срока, например "10 дней". Потому что это всегда вероятности:
Сначала я попробую простой(наивный) подход и это займёт день.
Если он не сработает - тогда второй, более сложный, и это будет неделя.
Если и это не сработает, и вскроются подводные камни от легаси кода и того, что проект вообще на это не рассчитан - то тут вообще всё переписывать нужно будет.
И вот эти "если" будут известны только после того, как сделал и протестил, а не до. В среднем, с учётом вероятностей, это и получится "10 дней", но это уже совсем та самая "средняя температура по больнице" из анекдота.
Нет, конечно, можно себе вообразить программиста, у которого достаточно мозгов, чтобы помнить и в уме мгновенно компилировать сотни мегабайт кода и наперёд знать, что именно и как будет работать, а что - нет, но такой человек бы сейчас торговал акциями на Уолл Стрит, а не сайтики кафешкам бы делал.
Потому что срок идёт в прямой зависимости от стоимости проекта.
Интересно-то как. Покажите мне, где уменьшение срока работы уменьшает её стоимость. Везде и всегда наоборот - срочное выполнение (меньше срок) стоит дороже, чем не срочное (больше срок). Или вы имеете ввиду, что себестоимость пропорциональна потраченному рабочему времени? Но рабочее время != срок. Это 9 женщин ребенка за месяц не родят, а вот разработка вполне себе интенсифицируется, и 9 программистов сделают работу в 9 раз быстрее, чем 1, а то и ещё быстрее. А ещё есть субподряд, и аутсорс, и дихотомия "сделать сам - купить готовое" для большинства подзадач. Поэтому стоимость и срок - это всегда два независимых в широких пределах параметра задачи.
Значит, вы ни разу не работали напрямую с заказчиком - мелким/средним бизнесом и частниками. Потому что срок идёт в прямой зависимости от стоимости проекта.
Если мы говорим про услугу стоимостью 5 т.р. - не стоит употреблять по отношению к нему слово "проект". "Проект" предполагает, что характерно, индивидуальное проектирование в соответствии с ТЗ заказчика. Ничто под индивидуальный заказ не может стоить таких смешных денег, тем более если это продукт работы высокооплачиваемого специалиста. 5 тысяч рублей в IT может стоить только серийный, потоковый продукт.
А стоимость им нужна ещё до заключения договора.
Разумеется, иначе что со стороны заказчика является предметом договора? Но как это мешает, например, разбить договор на этапы, в том числе обязательные и дополнительные?
Сначала я попробую простой(наивный) подход и это займёт день.
Если он не сработает - тогда второй, более сложный, и это будет неделя.
Если и это не сработает, и вскроются подводные камни от легаси кода и того, что проект вообще на это не рассчитан - то тут вообще всё переписывать нужно будет.
Мне вот очень интересно, как это у вас так (не) работает? Сначала пишете что:
а) Срок идет в прямой зависимости от стоимости.
б) Заказчик требует стоимость договора до его заключения.
Казалось бы, из (б) у вас есть стоимость, из (а) вы знаете коэффициент пропорциональности срока к стоимости, перемножьте эти две величины, пропорциональность между которыми вы сами и постулируете (я-то с этим категорически не согласен, но речь-то про ваши постулаты).
одно из отличий профессионала от дилетанта в том, что он осознаёт все потенциальные подводные камни и их влияние на сроки. И то, что срок - это не цифра, а вероятностная шкала.
Осознает, но не умеет оценивать их матожидание? Силен профессионал. А трудозатраты же тогда тоже "вероятностная шкала"? А как такой "профессионал", который не может оценить свои трудозатраты, стоимость считает? На основании чего он заказчику прайс озвучивает?
Это у дилетанта - "будем считать, что одна кнопка это один час работы. 80 кнопок = 80 часов = 10 дней".
Хреново, конечно, когда "специалист" умеет считать временные затраты только таким образом. Сочувствую, но не от всего сердца.
Позвольте, я объясню вам, как это работает. Допустим, ставка за 1 час - 3000 руб. для клиента. Делаем проект, получаем от клиента 3000*8*d*n, d, n >0. Где 8 - это количество рабочих часов в день, d - рабочие дни, а n - это кол-во спецов на проекте. Следовательно, если делаем проект за 3 месяца, то подставляем в формулу количество рабочих дней и спецов - получаем стоимость проекта для клиента. Формула упрощённая, обычно ещё коэффициент риска добавляется. Но он добавляется к срокам, а не к ставке. И ещё ставки у спецов разные. И сроки у каждого спеца отдельно считаются. А как спецы срок считают, это вообще тема отдельной статьи.
Улавливаете прямую взаимосвязь между сроками и стоимостью?
При этом есть ещё и прямая зависимость от количества специалистов. Чтобы ускорить работу, добавляют людей. Но 9 разработчиков не ускорят работу в 9 раз! Это ваши фантазии. Практика показывает, что чем больше добавляется спецов, тем больше падает эффективность. Ее съедает необходимость согласования деталей работы между собой. Затраты времени на коммуникацию растут.
Я видел зависимость ставки от типа проекта: Fixed-Price или «Time & Material», иногда выделяют Milestone, но там считается по фиксе обычно. И я никогда не видел в it зависимости цены от срока. Разве что у фрилансеров такое практикуется. А вы на полном серьёзе утверждаете, что:
стоимость и срок - это всегда два независимых в широких пределах параметра задачи.
Покажите нам такие it компании, где ставка за час работы специалиста для клиента зависит от срока! Хотя бы 2-3 примера дайте.
Вы, очевидно, не имеете отношения к формированию конечной цены (цена это не себестоимость, если что) продукта, и поэтому ничтоже сумняшеся переносите ваш опыт отношений работодатель-работник на отношения заказчик-подрядчик. Очень наивно и даже забавно, программисты в этом отношении инфантильны как дети, но к реальности это всё никакого отношения не имеет. И, вы серьезно думаете, что ваше руководство выставляет заказчику цену равную, ну или хотя бы даже прямо пропорциональную вашей ставке? Ох, в IT трудозатраты, конечно, занимают приличную часть в цене продукта, но не надо же понимать эту формулировку настолько буквально...
Покажите нам такие it компании, где ставка за час работы специалиста для клиента зависит от срока! Хотя бы 2-3 примера дайте.
Ваша компания сдает заказчику специалистов в почасовую аренду, или всё-таки выпускает для заказчика конечный продукт? Если второе, то заказчик платит не за часы работы специалиста, а за продукт. Стоимость продукта для заказчика зависит от срока. А не стоимость часа рабочего времени специалиста.
Давайте я вам объясню как это работает, и почему в IT, ровно так же, как и в любом другом бизнесе, цена находится в обратной зависимости от сроков. И причины этому не в особенностях разработки, а в особенностях бизнес-процессов:
-Риск. Сам по себе срочный заказ - это риск просрочить договорные обязательства. Просто потому, что вы беретесь за работу в более высоком темпе, чем обычно. Попасть на неустойку, испортить репутацию компании. Риск стоит денег.
-Приоритет. К моменту появления заказчика, у компании уже есть очередь заказов, и за дефолтный прайс заказчик идет в конец этой очереди. Хочет превратить эту очередь в стек - пусть доплачивает. Да, трудозатраты не увеличатся, но придется сдвигать приоритеты других заказов, а это риск сорвать сроки и попасть на неустойки уже по этим заказам. Риск стоит денег. К тому же сдвинуть сроки других заказчиков ради этого - это особое отношение к заказчику по сравнению с остальными, а оно само по себе требует материального стимулирования.
-Срочное привлечение ресурсов. Обычно возможности просто так взять и подвинуть остальные заказы настолько, чтобы впихнуть ещё один, физически нет. Тем более, что отрывать от проекта уже погруженных в него людей - опасно и неэффективно. Поэтому обычно для выполнения срочных заказов стараются по максимуму задействовать сторонние ресурсы - фрилансеров, субподрядчиков, или даже брать на срочный договор дополнительных сотрудников. Это почти всегда дороже. Надеюсь не надо хотя бы здесь объяснять, почему? Так мало того, это почти всегда менее эффективно. Потому что штатных сотрудников компания искала годами, кропотливо отсеивая хороших работников с и так дефицитного рынка труда. А тут приходится искать исполнителей очень быстро. Тем более что мало кто из хороших работников захочет идти на срочный договор в 2-3-6 месяцев, даже ради х2 к зарплате. Стабильность люди ценят очень высоко.
-Дихотомия "купить vs разработать". Не всегда, но очень часто, при решении задачи встает выбор: купить готовое решение, дорогое и часто избыточное по функционалу и мощности, сэкономив время, или сделать самим, но дольше и дешевле. Если заказ срочный, то в сроки можно уложиться только купив, потому что на разработать самим нет времени. А это повышение цены.
-Повышенные затраты на администрирование. Срочный заказ в определенной степени всегда ломает процессы в компании. И бизнес-процессы, и workflow. Просто потому, что все эти процессы оптимизированы под определенный темп и порядок поступления задач. И для того, чтобы управлять компанией с частично поломанными процессами, надо стимулировать управляющий персонал. Условно говоря, премии за срочный проект. Потому что именно они отвечают за сроки, и именно им предстоит искать, куда бы срочно всунуть объемы работ, где и какие сроки можно подвинуть с минимальным риском, где и какие внешние ресурсы можно привлечь. И делать это эффективно они за спасибо не будут.
Есть ещё несколько связанных с ресурсами факторов, не столь актуальных для чисто софтварной разработки, но очень важных, например, для разработчиков девайсов "под ключ". Но судя по вашим отдельным категоричным высказываниям, вы имеете дело только и исключительно с софтом.
При этом есть ещё и прямая зависимость от количества специалистов. Чтобы ускорить работу, добавляют людей. Но 9 разработчиков не ускорят работу в 9 раз! Это ваши фантазии. Практика показывает, что чем больше добавляется спецов, тем больше падает эффективность. Ее съедает необходимость согласования деталей работы между собой. Затраты времени на коммуникацию растут.
Это справедливо только если задача примитивная, скажем, канаву копать, или предлагалки соусов за 5 рублей на сайт пилить. Когда набирается 9 исполнителей с одинаковым набором компетенций, они друг другу больше мешают. Но для сложных задач, которые задействуют различные компетенции, оно вообще по-другому работает. Обычно наблюдается синергетический эффект - при правильном подборе команды, 9 исполнителей ускоряют работу больше, чем в 9 раз. Потому что один исполнитель, даже самый высококвалифицированный, не может быть хорош во всём сразу. Всегда найдутся подзадачи, решать которые он умеет плохо/медленно, а то и вообще не умеет. А в команду из 9 человек уже можно подобрать исполнителей, которые в сумме закроют своими компетенциями различные части и различные технологии задачи. Вы не представляете даже, насколько сильно это ускоряет процесс. И небольшие временные потери на коммуникацию на этом фоне вообще не замечаются.
У цены есть несколько определений, я использую этот термин в статистическом понимании, когда стоимость - это цена, помноженная на количество. Потому что речь шла про расчеты. Цена(ставка) в периоде полгода-год обычно стабильна. Ставки не меняются быстро. Можно условно считать их константой. А вот сроки (кол-во рабочих часов) всегда разные у проектов. Вот и получается, что есть прямая зависимость стоимости проекта от сроков! А вы утверждаете что стоимость и сроки независимы друг от друга в одном комментарии. А в другом уже пишете наоборот. Вы уж определитесь!
Далее. Сейчас все профессиональные it-компании в сфере разработки ПО на заказ работают на основе ставок за час (рейтов). Возможно, исключением являются тендерные проекты, да и то, даже там компании все равно считают уровень своей маржи, сравнивая с имеющимися рейтами, прежде чем браться за них.
Понятие продукт важно для продуктовой компании, но это совсем другая история. А для разработчиков на заказ - продукт это лишь сколько-то часов работы, за которые заплатят. Немного цинично, но это факт.
И, вы серьезно думаете, что ваше руководство выставляет заказчику цену равную, ну или хотя бы даже прямо пропорциональную вашей ставке
Вероятно, вы путаете внутренние рейты спецов (что есть коммерческая тайна) и внешние (для клиента). Мы про внешние обсуждаем. Не трогая себестоимость.
Про 9 исполнителей - я вас не понимаю. Вы про команду в целом пишите что ли? Типа бек, фронт и т.д.? Конечно, если аналитика заставить писать бэкенд - это будет очень долго))) и привлечение бэка ускорит работу куда больше, чем в 2 раза)) Но это же очевидно. Если имеется в виду , допустим, только бэк - то все зависит от архитектуры проекта. И от уровня компетенций разработчиков.
Про некий грамотный подбор кадров и синергетический эффект- мы же в реальном мире живем, не так ли? Теоретически это возможно, а практически - нет. Обычно все получается наоборот.
Каждый новый разработчик требует онбординга (погружение в проект), что отвлекает ресурсы того же лида, например. В сложных проектах онбординг может и больше месяца идти. А потом в процессе еще возникают всякие ситуации, типа фронт просит бэка что-то переделать в апи, бэк утверждает, что это надо на фронте делать, подключается лид, разруливает. На обсуждение каждый потратил минимум 1ч. Коммуникация на 3 человека - 3ч. Такие коммуникации каждый день идут.
А если бэку в тз что-то непонятно? Он идет обсуждать вопрос к аналитику (или к pm), тратиться еще полчаса-час. Таких разработчиков 8 чел, каждый сходит к аналитику разок в день, аналитик уже минус, вместо анализа новой фичи он тратит время на разъяснения, возможно требующие потом дополнительных правок в тз. Работа аналитика буксует. Нужен еще человек. Появляется еще аналитик - теперь двум аналитикам еще и между собой надо согласовывать функционал. А разработчики ходить к аналитикам не перестанут, просто будут ходить к 2-м людям. И будут возникать такие ситуации, что аналитик после 15-20 мин обсуждения понимает, что это зона ответственности другого аналитика…Что будет происходить дальше, вы уже должны догадаться))
Я так могу еще долго накидывать примеры, как коммуникация и проблемы начинают расти как снежный ком. Как зацикливание коммуникации происходит и т.д. Вы уж извините, но у меня сомнения, что у вас есть реальный опыт для обсуждения всех этих вопросов. И судя по минусам, так думаю не только я.
Да любая работа по T&M. Переработки свыше 8ч - х1.5, выходные х2. Тут ставка зависит от производственной необходимости , то есть срока.
а вот разработка вполне себе интенсифицируется, и 9 программистов сделают работу в 9 раз быстрее, чем 1
Нет. Вообще нет. И не близко. Это работает в очень ограниченном виде.
Для доказательства этого предлагаю посмотреть на историю разработку Windows Vista и то сколько кругов ада она прошла прежде чем появилась на свет, при том сколько там разработчиков работало.
Ну как это? 9 женщин родят ребенка за месяц же, а вы проект не сможете сделать? :)
Это могло бы стать доказательством только если бы мы знали, сколько заняла разработка Windows Vista силами одного разработчика. Тогда мы могли бы сравнить: вот, 100К разработчиков разработали её за год, а один разработчик - не за 100К лет, а всего за 50К. Или, наоборот, за целых 200К лет. И смогли бы сказать, приводит ли интенсификация к повышению или понижению эффективности.
А здесь с чем вы предлагаете сравнивать эффективность? С другим программным продуктом? А у него другая трудоемкость, сравнение будет некорректным.
Чуть ли не 10 лет назад (если не больше) всплывала переписка внутреняя майкрософта как они бомбили при разработке Vista мол почему у нас 100500 инженеров какой год уже не могут композитный оконный менеджер сделать (делали в рамках Whistler / Longhorn / Vista), а эпл мол на недавнем девелоперском мероприятии презентовала уже это как готовое, среди остальных новых фич, мол у них на два порядка меньше инженеров, какого чёрта.
9 программистов сделают работу в 9 раз быстрее, чем 1
Не сделают, причем причина легко описывается поговоркой "у семи нянек дитя без глазу". 9 программистов сделают работу в 9 раз быстрее, чем 1, если только они будут заниматься разными частями проекта, мало влияя на работу друг друга, в остальных случаях они будут друг другу мешать и в этот коэффициент вы не попадете, если сделают хотя бы в 3 раза быстрее уже это успехом будет. Я сталкивался с таким на практике
Брукс прямо говорил что добавление людей на проект увеличит время на разработку. Причём неважно вообще сколько их было изначально хоть 1, а потом 2. Причём это также работает и на команды. Команда из 5 человек работает в 2 раза быстрее команды из 7-8 и в 10 раз быстрее чем из 15.
Также количество багов это статическая величина на количество строк код. Условно +500 строк в проекте добавит 1 баг.
80 часов = 10 дней".
Вполне возможно что месяц. Потому что отпуск, или праздники. Или просто релиз запланирован.
Но когда разработчик рядового программного продукта заявляет, что его задача слишком сложна для того, чтобы оценить сроки выполнения...Хочется спросить - а как вы вообще работаете?
Вы когда-нибудь видели как происходит разработка? В 7 из 10 случаев требования меняются на ходу - удачи оценивать сроки этого.
Для "привет, созвонимся на пару минут?" есть отдельный котёл в аду. Для собеседника это звучит "привет, давай ты прямо сейчас бросишь абсолютно все свои дела и уделишь все своё внимание мне, причём даже не зная, зачем".
Вот в точку. Это банальное неуважение к своим коллегам.
Спокойно отвечаю на такое "да, без проблем, кинь встречу в календарь". Примерно в 10% случаев действительно кидают, ещё в 40% пишут вопрос текстом, в остальных исчезают)
Правда, у меня работа почти вся на созвонах, и календарь обычно забит на пару дней вперёд. Возможно, это как-то влияет на результат)
Спокойно отвечаю на такое "да, без проблем, кинь встречу в календарь". Примерно в 10% случаев действительно кидают, ещё в 40% пишут вопрос текстом, в остальных исчезают)
И теряете 40 минут на то, чтобы, блин, обратно сконцентрироваться на задаче. Красота.
Работай помидорами, смотри чаты/почту до/после паузы, выключай на продуктиный период.
Вот не уловил, где вы тут увидели потерю 40 минут?
Я кстати примерно так же обычно поступаю. Потому что это правильно - прежде чем "созвониться на пару минут", извольте изложить свой вопрос текстом. И найдите в моем календаре свободное время. Чтобы я подготовился, и понимал, что мы вообще собрались обсуждать.
Сижу, думаю о серьёзной задаче, тут сообщение, я отвлекаюсь, восстановление контекста и концентрации требует конкретного времени.
Если муха пролетит или за окном звук какой?
Тоже слетает концентрация?
Не стебусь. Действительно интересно, как от этого спасаетесь.
Меня сильно не отвлекают чаты и тд и тп, если концентрация идет. Я просто их игнорю. Если же звонок приходит, то придется отвлечься, чтобы выслушать и принять решение - дальше говорить или перенести встречу на попозже
Иногда такие отвлечения приводят к полезным и новым идеям по задаче.
Буквально на днях часа 3-4 пыхтел над алгоритмом и не отвлекался. На следующий день продолжил так же, но через час работы кто-то реально отвлек. Когда вернулся к работе, то пришла такая идея, что переписал все за минут сорок и очень круто упростил все процессы.
Вот и подумаешь, а стоит ли быть в полном вакууме от внешнего воздействия...
Если муха пролетит или за окном звук какой?
Ну я как бы продолжительное время работал в науке. Там задачи сложнее, и концентрацию требуется держать дольше.
Я просто их игнорю.
Если вы прочтёте комментарий, с которого началась ветка, там предлагается делать триаж сразу по получении сообщения. Вот этот триаж предполагает, что вы выгружаете контекст, над которым работаете, чтобы загрузить новый и сделать триаж. Дело в том, что вероятность того, что вас спросят ровно по той задаче, над которой вы работаете сейчас, мала - обычно висят же несколько разных задач.
На следующий день продолжил так же, но через час работы кто-то реально отвлек. Когда вернулся к работе, то пришла такая идея, что переписал все за минут сорок и очень круто упростил все процессы.
Я уже довольно давно сам отмечаю, когда некоторое время не могу дальше продвинуться. Как правило, это означает, что где-то не хватает каких-то данных. Дальше стандартные вещи - ищем, где же именно не хватает, переходим в над или под систему для определения этого.
Увы, я неправ - триаж не требуется. Но меня такое, увы, отвлекает, т.к. я его автоматом делаю.
Благодарю за развернутый ответ. У нас с Вами частично похожие процессы обработки задач.
Свой триаж провожу 2 раза в день:
- Утром, до начала рабочего дня. Люблю час поработать в полном отключении от коммуникаций, если позволит ситуация. Просматриваю переписку - если могу сразу ответить, то отвечаю сразу. Если требует обработки и подготовки - то завешиваю задачей относительно ожидаемого дедлайна по финальному ответу (предварительно отвечаю на письмо с ожидаемой датой). Если письмо переслать - пересылаю. Если письмо в корзину - значит в корзину.
- после обеда. Смотрю на отправителей (есть фильтр-вотчдог на определенные ФИО), если их нет, то просто сворачиваю outlook.
----
Если кому-то горит, то пишут в мессенлжеры (на десктопе читаю - когда есть желание посмотреть).
В случае ахтунга - позвонят.
Так и живем :)
Спокойно отвечаю на такое "да, без проблем, кинь встречу в календарь".
Вот что конкретно было сделано. Если это вас сбивает с концентрации - ну я не знаю. Это более чем рутинное движение, не требующее приложения мозгов практически.
Ну то есть я в целом понимаю, о чем вы, но то чего вы желаете, достигается только способом "не читать ваще эту почту весь день". Иначе отвлекать все равно будут. А не читать весь день не все могут позволить.
Так тоже не всегда правильно, часто по вопросу нужно решение относительно срочно. Допустим часто приходят аналитики с вопросами по текущей логике, тестировщики с вопросами по задаче. Закидывание в календарь может в таком случае сильно тормозить работу и неудобно - спрашивающему придется ставить работу на паузу, потом возвращаться в контекст.
В принципе в "созвоне здесь и сейчас" нету ничего сильно криминального. Другой вопрос - что часто вопрос может быть в принципе такой, что ты не можешь на него ответить. Или наоборот - ответ в итоге очень простой и его можно отписать за пару секунд, не переключая внимание. Я например без проблем могу ответить на быстрый вопрос в чате не выпадая из фокуса, созвон же это всегда полное переключение внимания. Ну или вопрос "на пару минут" часто может оказаться не на пару минут, и тогда наоборот можно быстро ответить "там долго разбираться, давай попозже подробно созвонимся".
спрашивающему придется ставить работу на паузу, потом возвращаться в контекст
А отвечающий, в вашем понимании, работу на паузу не ставит, он постоянно сидит в режиме ожидания ваших вопросов? Вы одной фразой охарактеризовали своё отношение к коллегам и даже не поняли.
Я например без проблем могу ответить на быстрый вопрос в чате не выпадая из фокуса
Поздравляю, а кто-то не может. Что ему - вешаться? Или работать, когда все такие торопыжки разошлись по домам?
Воу-воу, сколько агрессии и на пустом месте. Я просто говорю что решать все вопросы только через встречу в календаре это другой экстрим и нужно более понимающе друг к другу относиться.
Дело в том, что это разные "поставить на паузу". Да, тому у кого спрашивают нужно отолжить текущую задачу на 15 минут или даже скажем, в худшем случае, на час-пару часов, но потом можно спокойно продолжить ее делать. А тот кто спрашивает, если он не может без ответа продолжить работу по задаче, ему что делать? Брать другую? Это и нарушение процессов (несколько задач в работе одновременно), и распыление внимания, да и вернуться в контекст после 15 минут\часа или после 2-х дней, разные вещи.
сколько агрессии и на пустом месте
Да судя по вашему ответу абсолютно не на пустом. Вы только подтверждаете мой вывод
в худшем случае, на час-пару часов, но потом можно спокойно продолжить ее делать
Про состояние потока что-нибудь слышали? Бывают такие задачи, что если тебя отвлекли, то сегодня ты к ней уже не приступишь - контекст потерян, мозг выдал всё, что мог.
не может без ответа продолжить работу по задаче, ему что делать?
Попробовать выяснять все вопросы непосредственно перед тем, как приступить к выполнению задачи. Говорят, это признак профессионализма. Также поможет вам корректно оценить сроки. Если вы ныряете в задачу как в омут, не потрудившись даже проанализировать, какие в ней могут быть подводные камни - это исключительно ваша проблема.
Это примерно как "можно задать вопрос?" в общих чатах, только хуже.
Если человек (к тому же аналитик в данном случае!) не может потратить пять минут на сбор мыслей в кучку и хочет вместо этого помычать в трубку, это читается как очень однозначный посыл: "моё время ценнее твоего".
Бывает трудно сформулировать, да. В вопросе, как известно, половина ответа. Но это всё ещё можно (и нужно) сделать на доступном уровне. Но автор почему-то упорно идёт обходным путём и множит корпоративное насилие. Не надо так.
Джун аналитик уже звучит гордо. :) Сначала наплодили кучу разных должностей-прослоек в it, потом ввели полную удаленку, и тут удивление сложностям коммуникации при введении новых людей.
Хэштег #раньшебылолучше?))
Ну я лично не понимаю разделение аналитика и пм в общем смысле, часто получается конфликт интересов и недопонимание между ними и лишние связи для команды разработчиков. Условно пусть будет один "универсальный" человек на проект чем ПМ будет вести 2 проекта и аналитик 2 проекта параллельно. Там как правило никакого рокет сайнса нет между этими должностями, по хорошему и тот и другой должны быть технически подкованы.
За "Привет, наберу на 2 минуты?" - я готов убивать, т.к. этим человек пытается вырвать меня из запланированных дел.
Точно также, как и назначение встречи в календаре за 10 мин до её начала. Я такое просто отменяю. Хочешь созвон? Запланируй за 1-2 часа минимум.
Так же ненавижу тех, которые зная что вопрос не на 5 минут(30-90 мин на обсуждение), ставят в календарь, созвон на 15 мин, а потом удивляются что у тебя есть другие дела и ты отключаешься.
За "Привет, наберу на 2 минуты?" - я готов убивать
Нас еще вымораживает сама формулировка своей нелогичностью. Мы-то откуда можем знать наберет он или нет? Это должно звучать как. "Есть ли возможность сейчас выделить 2 минуты на телефонный разговор?".
Я кидаю ссылку на толк, в котором я сижу в таких случаях. Ну и контекст вопроса конечно, с указанием почему это не текстовый вопрос. Даже если это звучит как "по задаче ХХХ, я совсем не врубаюсь как у нас там интеграция настроена"
Есть у человека время - он зайдет, нет времени, но есть идея что мне поможет - напишет полезный ответ, нет времени и идей как мне помочь - откажется или проигнорирует.
Сижу в созвоне до появления человека, ответа или 15 минут. Если не пришли - стираю ссылку, чтобы не зашли, когда я уже вышел.
А иначе действительно, лишняя мета, как "привет, можно задать вопрос?"
Мы немного о другом.
На западе сейчас стало модно говорить "о своих чувствах" вместо того, что бы "указывать другим что делать". Типа "мне неприятно что ты капаешь мне раскаленным оловом на голову" (из анекдота) вместо "перестань мне оловом на голову капать". Эта псевдовежливость из бытовухи перетекла и в рабочие отношения, а теперь и в россию. Почему псевдовежливость? Потому что человек вместо того, что ему собственно нужно - заставляет Вас догадываться для чего он это сказал, то ли просто уведомил, то ли просит помощи, то ли еще что-то.
Фраза "я не совсем врубаюсь как" уведомляет о трудностях. Но не дает никакой информации о том, что нужно от собеседника и зачем вообще это было сказано. Так сказать это State хотя нужен Call to Action. Вместо этого адекватнее сказать "мне нужно объяснение как это работает, дайте сами или скажите к кому обратиться".
Я специально привел самый размытый вариант формулировки. Ситуация, когда я не могу сформулировать вопрос, так как не знаю о чем спрашивать. 2 интегрируемые системы я в реальности конечно указал.
Но обычно вопрос еще конкретнее, просто он подразумевает цепочку уточняющих в зависимости от ответа на первый. А асинхронные цепочки это зверски долго.
Размытость была бы, если бы был хоть какой-то призыв к действиям, ту же проблема в его полном отсутствии.
Упростим для ясности.
"Я не понимаю как это работает" - это констатация факта и все.
"Объясните как это работает" - это четкое выражение просьбы.
Первое годится для отчетов, типа я прочитал и ничего не понял, нотникак не годится для просьбы объяснить что-то.
Не знаю на счёт моды, но то что Вы описываете похоже на неправильное использование психологических методик и подходов. Это никак не связано с вежливостью и используется по-другому и для других целей.
Объясню коротко на аналогии. Пришла мода на С++, но это плохой язык, потому что им можно выстрелить в ногу.
Можно в С++ выстрелить в ногу? Можно. Это минус языка, минус. Можно ли не стрелять себе в ногу? Можно. Нужно ли переставать этот язык использовать? Нет. Плохой ли этот язык? Зависит от того кто и как его применяет.
Царапнуло глаз "прошу Вас..." - по правилам русского языка достаточно вас с маленькой буквы. Большое "Вы" - в очень редких случаях, точно не про внутреннюю переписку.
По теме выделил бы основную проблему - вам не отвечают! Далее куча вариантов... В первую очередь - должны ли вам вообще отвечать?! Если ваши вопросы могут игнорировать - они будут проигнорированы. Это нормально, потому что: 1) работа, 2) лишние контакты отвлекают, 3) частичный ответ или ответ не в тему могут усугубить проблему.
Если "должны отвечать" - то это локальная задача управления. В первую очередь вам дается ответственность за какой-то спектр задач и полномочия требовать информацию. Далее - разумный срок ответа. Если ответа нет, то обращаться к непосредственному начальнику. Если проблема не решена - уровнем выше.
И здесь речь не про токсичность, а про то, что у вас простой в задаче, за которую вы получаете зарплату. А отсутствие срока какой-то работы весьма вероятно указывает на какую-то проблему, которую должен решать уже другой уровень управления.
З.Ы. в примере приторного письма зубодробительная канцелярщина - 5 баллов из 5!
"Прошу, Вас" - это уважительное обращение к конкретному человеку.
"Прошу вас" - это обращение к группе людей.
Уважительное с определенными интонациями, которые отражают Большое Уважение в редких случаях официального и личного обращения. ВО ВСЕХ ДРУГИХ случаях достаточно маленького "вы".
Это старый холивар который в основном сводится к тому, какой возрастной категории человек. При ссср и некоторое время после него учили, что к одному человеку всегда "Вы". Начиная с нулевых большая буква стала отмирать, вплоть до того, что сейчас написание "Вы" с большой буквы, даже при Большом Уважении могут счесть ошибкой и в школе и в универе.
Ну вообще написание "вы" со строчной или прописной буквы - контекстуально.
В обычной переписке с коллегой, с которым вы не переходили на "ты", в этом нет нужды. В обращениях же, различных письмах, заявлениях, в общем, когда нужно подчеркнуть торжественность и/или официоз документа, "Вы" обычно пишут с большой.
Расскажу, как я вижу ситуацию со своей колокольни, как программист. Если мне пишет ПМ/бизнес-аналитик/клиент/дизайнер, я всегда стараюсь ответить сразу, т.к. 30% вопросов можно решить сразу (вопросы из разряда где искать какие-то настройки или готово ли что-то). Ещё 30% требуют уточнения, согласования, дополнительной информации и т.д. В таком случае удобно бегло глянуть на вопрос, задать уточняющие вопросы и тем самым отфутболить задачу на другую сторону. И по своему опыту я могу сказать, что если отвечать на письма и сообщения сразу, то в первую очередь экономишь своё время. Тот, кто копит корреспонденцию, чтобы потом всё вместе разобрать, просто ворует время в первую очередь у себя, во вторую у остальных. Конечно, у каждого есть своё оправдание, впрочем, у каждого нашкодившего школьника тоже есть оправдание.
А теперь, самое интересное, как быть, если ты пишешь, а тебе не отвечают? Когда долго работаешь с одними и теми же людьми, то уже знаешь, кто отвечает в течение часа, кто отвечает раз в день, а кто вообще никогда не отвечает (да, есть и такие). И если ты достаточно долго работаешь с этими людьми, то ты уже знаешь, что ты никак не можешь повлиять на их стиль общения. И приходится с этим жить. В таком случае единственный правильный вариант - учиться решать вопросы самому, а те вопросы, что не можешь решить, нужно задавать максимально чётко. И очень часто бывает так, что пока пишешь развёрнутый вопрос кому-то, сам же понимаешь, как его решить. Ну и опять же, если вопрос касается поставленной задачи, то если задать его сразу, то значительно выше вероятность что на него сразу же и ответят, чем если ждать неделю, а потом спрашивать, когда все уже и забыли, о чём эта задача была.
И по своему опыту я могу сказать, что если отвечать на письма и сообщения сразу, то в первую очередь экономишь своё время. Тот, кто копит корреспонденцию, чтобы потом всё вместе разобрать, просто ворует время в первую очередь у себя, во вторую у остальных.
Жаль, что не все в айтишке так мыслят.
О да, а ведь некоторые копят не сообщения, а пулл-реквесты. У нас бывает такое, что сделал задачу в понедельник, оформил пулл-реквест, QA одобрил, в пятницу надо делать другую задачу, которая основывается на той, что делал в понедельник, но тот пулл-реквест до сих пор висит, потому что у тимлида не было времени его посмотреть. А когда у него будет время, то из-за того, что пулл-реквестов накопилось больше 30 штук, ты будешь полдня делать rebase и разрешать конфликты всего того, что сделал за неделю.
От этого очень помогает норма 36ч на ревью. Если спустя 36ч нет ревью задача заливается как есть под ответственность тимлида.
Пулл должен читаться за 10-15 минут целиком. Если мне пришлют партак на 500+ строк я просто нажму "отклонить" неглядя и так пока человек не научиться нормально работать и не тратить чужое время на чтение киллометровых партянок
Ну т.е. задача из новой разработки с тестами условна на 2 дня это много? И надо делать несколько коммитов и жать одобрения на каждый?
Я обычно смотрю на интерфейсы в этом случае и на семантику тестов для ревью, реализацию по диагонали.
Или Вам нравится раз в несколько часов делать ревью каждый день?
Нет это значит что если у тебя огромные пуллы на больше чем 500 строк и 20-30 файлов то ты плохо провел декомпозицию.
Я тоже думал что пулл на 800 строк и 30 файлов норма, но потом меня кочергой отымели и внезапно даже удобнее стало продумать заранее разбить на под задачи и делать небольшие пуллы по 200-300 строк.
Не норма, но иногда они случаются. Вот реально для задач на 2 дня разработки бывало, например надо много тестов и т.п.
Да, декомпозиция хорошо, но сколько ж раз тогда надо подходить к код ревью если вся команда будет давать на ревью одну- две задачи в день.
Это сильно противоречит другой этике (тоже не на пустом месте возникшей) - любая задача должна быть целостной, то есть не просто работать независимо от соседнего кода, но приносить пользу бизнесу в таком виде.
И вот уже ты не можешь одним коммитом засунуть бэк, а вторым интерфейс к нему. А нужно в один коммит утоптать:
хранение данных,
админку для их первичного ввода,
алгоритмы в повседневных процессах, которые ими пользуются
изменение в интерфейсах рядовых пользователей системы
Крутая мысль, надо подумать, как это автоматизировать. Можно ещё тимлиду слать письма с девочкой из "Звонка" и подписью "осталось два дня" :D
Я, конечно, напишу шовинистский комментарий, но включите пару раз видео на встречах и поставьте везде аватарку =) это немного добавит предубеждения, но точно увеличит внимание к вашей персоне, разработчики они такие... ?
А по делу - как уже написали, красный шрифт и «позвоню на две минуты» через несколько итераций приводят к тому, что вас будут игнорировать специально. Я, наприм, на подобные вещи начинаю отвечать, чтобы ставили созвон на такой-то день, даже если свободен, а то сядут на шею и будут звонить, хотя могут сами решить вопрос поиском за две минуты.
Часто игнорирую письмами потому что сидишь кодишь и тут кто-то с ноги открывает дверь и просит ответов на неё интересные вопросы. Да пнх так вырваться в рабочий процесс.
У меня сроки по задачам горят, а тут ты со своими вопросами.
У себя в команде выделил время (3 раза в неделю по часу) когда ты можешь прийти с вопросома и мы все детально обсудим) но у меня не большая компания и команда.
П. 3 - лично я считаю, что ВОПЛИ (а именно так в письмах воспринимается красный шрифт, увеличение кегля и прочее) в деловой переписке совершенно неуместны. Есть прекрасные средства выделения - подчеркивание, болд, курсив; как показывает моя практика, они прекрасно работают.
П. 4 - позволяет, конечно, решить ваши тактические задачи, но будьте готовы, что это вызовет недовольство и нелюбовь к вам. Кроме того, я, как руководитель, категорически не приветствую такого - во-первых, я прекрасно понимаю, что это вызывает неудобство у подчиненных; во-вторых, иногда добавляют в письма с запросами а-ля "Сколько скрепок вы за день потратили, ВАЖНО!!!!1111 СРОЧНО!!!1111"; в-третьих, если вопрос действительно важный, то нужно не играть в открытость и горизонтальность, а прямо мне, как руководителю, и написать, какая информация вам нужна, для чего и в какие сроки, дальше я сам разберусь вместе с командой.
Текст почему-то строится только вокруг вопроса "как достучаться до коллег, если они не отвечают".
Но есть же и другая сторона дела.
Иногда запросы, например, бывают слишком размытыми. "Расскажите мне всё обо всём". Кому? Что? Зачем?
Иногда у человека есть другая задача, а ответ на вопрос требует ощутимого времени. Руководитель вряд ли примет общение с аналитиком со стороны как уважительную причину сдвига сроков.
Иногда для начала взаимодействия вообще необходим какой-то заход со стороны менеджера. Если проект общий, то команды надо как-то познакомить. Если нет, это сторонняя команда, то за ресурсом отвечающего должен идти опять же менеджер. "Подскажи, кто из твоих ребят мог бы дать ответ моему аналитику?"
Разумные рекомендации. Единственное при предложении звонка на 2 минуты имеет смысл уточнять что будете обсуждать и почему это важно, что это блочит.
Трагическая история про мальчика, который слал письма "Волки!" красным капсом, ставил в копию старосту деревни и постоянно назначал личные встречи односельчанам-охотникам. Все знают, что с ним в итоге случилось.
"Подскажите, пожалуйста, по срокам смежников" - выглядит как сообщение на которое не захочет отвечать даже самый общительный и ответственный сотрудник, которому весь день нечего делать.
Это Сбер)
Нужно конкретно озвучивать проблему. Ленивая формулировка получит ленивую реакцию. Я же вижу сразу - человеку было лень потратить лишних 15 минут, чтобы описать суть проблемы. Контекст давать обязательно.
А всего-то нужно:
Мы делаем то-то. У нас случилось то-то. Нам нужно то-то, чтобы то-то.
Почитайте Чуковского:
А потом позвонили цапли:
— Пришлите, пожалуйста, капли: Мы лягушками нынче объелись, И у нас животы разболелись!
Что надо, что случилось и почему.
Ясно и емко описывать суть проблем это вообще самый первый навык любого аналитика.
Не нужно надеяться, что кто-то что-то додумает или поймет магическим образом, а также что все знают чем вы занимаетесь или чем вообще занимается фирма, или отдел. На самом деле никто ничего не знает, и чем конкретнее будет вопрос тем больше шансов на ответ.
Не нужно бояться сухих деловых формулировок. Они куда приятнее обтекаемых глаголов. И все просьбы лучше в личной формулировке, чем в обезличеной. "Мне нужно..", "Я хочу..", "У меня .."
Я - это самое честное местоимение. Потому что ваш оппонент всегда отвечая вам делает одолжение. Лично вам. Сделайте так, чтобы ему хотелось помочь вам. К чему эти обтекаемые "сориентируйте". "На север, йопта!" Или какой ответ можно дать на такую просьбу?
Пользуйтесь нумерацией. Так оппoненту легче понять, что от него требуется:
Для того чтобы [...], мне нужно знать
дедлайн по функции <такой-то>
сроки выполнения задачи <такой-то>
Групповые письма допустимы в одном единственном случае: если нужно проинформировать эту группу адресатов. Вопросы группе это зря потраченое время.
Начальника добавлять в копию вообще моветон. Потому что он скорее всего считает, что для эскалации не было никакой причины. Создается впечатление, что сотрудник не в состоянии самостоятельно наладить контакт, найти подход к людям и постоянно нуждается в "заемном авторитете". Я думаю, что после пятого-шестого таког письма начальник попросит так больше не делать.
Насчет звонков с наскока. Я бы тут тоже к просьбе о звонке добавлял суть вопроса, а потом уже спашивал когда оппоненту будет сподручно поговорить.
"Привет, у нас цапли лягушками объелись, нужны капли. На складе сказали что вы брали большую партию, может что осталось? Если есть варианты, давай обсудим по телефону, когда тебе будет удобно."
Вопрос в чате должен быть в идеале сформулирован так, чтобы звонок был не нужен.
Вобщем, писать надо так, чтобы на ответ требовалось как можно меньше энергии.
Я для себя в своё время выработал такую формулу:
"Если уж всё же приходится задавать вопрос - ВСЕГДА представляй что на том конце переписки - полнейший тупица, не владеющей ситуацией и контекстом, и разъясняй ему всё как условному третьекласснику: что ты делаешь, что за задача (со ссылкой на трекер/гитлаб/етц), что необходимо сделать, какие симптомы, что пробовал (попунктно) и с какими результатами (попунктно), что гуглил, что нашел, что из нагугленного применял, ну и т. д"
И в свою очередь терпеть не могу когда вопрос, задаваемый мне, приходится выдергивать из просителя клещами, а ля "у меня сломалась система, всё исчезло!111 Помогите!!!1!11"
Что сломалось то???
Какая система???
Какие симптомы???
Что предшествовало???
Ненавижу
Как разработчик, я разработал себе свод правил деловой переписки:
Ответ на письмо точно будет дан в течение 24 часов с момента получения.
Все митинги должны быть запланированы не менее чем за 24 часа. (Исключение — другие разработчики, но там договариваемся через мессенджер).
Почта проверяется 2 раза в день — в начале и в конце рабочего дня.
Ответы на сообщения в мессенджере будут даны в течении 1 часа с момента получения.
Звонки на мобильный допускаются только в экстраодинарных случаях требующих незамедлительного вмешательства (хакерская атака, деструктивное ПО, пожар итд.)
Потому хоть выделяйте текст фиолетовым в крапинку, хоть ставьте СЕО в копию, оно будет прочтено когда прочтено.
в начале и в конце рабочего дня
То есть в один момент времени, но 2 раза. По мне лучше утром и в обед. На крайняк вечером глянуть, что ничего не сгорает, но на рядовые письма отвечать все равно утром.
вы что про разные часовые пояса не слыхали? У меня с утра куча писем к прочтению из таймзоны USA и LA ожидают прочтения
Встреча или звонок. Такой формат просто невозможно проигнорировать
Привет, наберу на 2 минуты?
Нет, я занят. Напиши что хочешь или давай через часов 5 поговорим.
Чем занят? Да не поверишь, работаю я. Сижу код пишу. Сроки нужны? Ну так у нас оценка задач по понедельникам раз в две недели в начале спринта, че ты ко мне ломишься? Ааа это срочная задача? Ну тогда сходи пусть ко мне придёт менеджер проекта и лично скажет бросить все и делать это, а ты не он.
Я один из тех людей, который игнорирует.
Игнорирую потому, что большой поток вопросов от разных людей и разных команд. И когда приходит большое письмо от смежной команды, то я понимаю, что мне нужно пол часа или час что бы вникнуть в суть и дать развернутый ответ. Не всегда на это есть время, поэтому вопросы остаются без ответов. И не важно письмо было от зеленого джуна или от лида команды.
Я и сам сталкиваюсь этим и приведенные советы помогают. Логика, наверное, тут такая, что если очень надо, то человек до любого достучится. А если не достучался, то наверное и не очень надо было.
Ни в коем случае не воспринимайте игнор на личный счет. Скорее всего, тот кому вы пишите сейчас перегружен.
Оффтопик, но, позволю себе дать еще один совет для професионального развития. Отбросьте "джуниора" из самоназвания своей профессии. Так вы быстрее будете расти именно в профессиональной области. Потому что вас будет заботить не новый титул, а новый опыт. Если хочется или нужно указать на количество профессионального опыта, то лучше сказать сколько лет ты на этом поприще работаешь. Выводы люди сделают сами. А все эти градации они ведь очень условны. Да и как правило рознятся от фирмы к фирме и их значения.
Поэтому для меня "начинающий аналитик" звучит куда более ответственно и честно, чем джуниор-аналитик. Это как "я только заспавнился, у меня иммунитет к урону! И ПВПшить меня нельзя! И если че, я вызову моих согильдийцев, мага и паладина 40 уровня, они вас всех ушатают. Эй, Мага, ну-ка, кинь в него файерболом. Вот! ПонЯяял! :P Ну, кто теперь нубас? А?". (Прошу прощения за мморпг-шные аналогии, но это была моя школа социальной психологии тогда в 2006 году. :)
Слово "начинающий" также указывает на то, что вы встали на определенный осознанно выбраный, профессиональный путь, и идете по нему. А не "сели на должность". Динамика - статика. Не знаю, наверное это трудно прочувствовать. Но в моем сознании я это очень четко отделяю. Слова имеют значение.
Лично для нас начинающий=джун, обычный=миддл, профессионал=сеньор просто синонимы. Честно говоря, Вашу точку зрения встречаем первый раз.
Дело в том, что такие классификации косвенно легитимизируют социальное неравенство в корпорации. Содают искуственное ощущение прогресса. Заменяя профессиональный рост, выдумаными градациями. Они первоочередно служат для рассчета финансовой компенсации и всех вытекающих отсюда рассчетов, и тем самым являются имагинативным индикатором субъективной полезности, ценности сотрудника. Которая может не иметь ничего общего с его действительной полезностью и вкладом в проекты.
Как относятся к джуну? Правильно, снисходительно. Так вот как он будет тренировать свои навыки если все с ним играют в "поддавки"?
Я как-то удивил своего учителя по игре Го, когда отказался играть с форой, потому что фора искажет ситуацию на доске, лишая тебя возможности тренировать дебюты.
В академической среде даже младших и старших сотрудников давно упразднили.
Я надеюсь, что есть фирмы, которые относятся ко всем сотрудникам как к полноценным людям, всецело доверяя им, и не унижая их классификациями, и градациями.
Непонятно почему такие вопросы в принципе решаются письмами, это в большой-то компании. Нет никакой CRM? Где можно указать нужные сроки ответа, приоритет, адресата и так далее? Все проблемы с красными шрифтами, капсом, телефонными звонками и логами дат ответов снимаются на раз-два.
"Привет, давай созвонимся на пару минут" - НЕТ.
"Привет, я настраивал Dockerfile для nginx и он при запуске он выдает ошибку XXXX. Помоги плиз" - ДА.
Как коллега аналитик, могу дать советы которыми я пользуюсь при общении с разработчиками.
1) Прежде чем звонить человеку, сформулируйте список вопросов письменно и отправите ему в чате или в письме, если по ответам возникнут вопросы, так же письменно попросите прокомментировать непонятные вещи и только если останется недопонимание, его уже можно будет предметно обсудить, 90 % что вам даже созвон не понадобится.
2) Старайтесь закладывать в любую задачу не оптимистичные сроки, а пессимистичные, помните, другие люди как и вы работают и у них может быть огромный список задач, сразу они вам не ответят и задачу не сделают.
3) Перед тем как спрашивать, у архитекторов или разработчиков, как работает та или иная функция, лучше пойти прочитать документацию проекта, чтобы иметь представление хотя бы частичное, о задаче, может и спрашивать тогда нечего не придется. ( Если документации нет вообще, тут конечно беда)
4) Если вам дали задачу и вы ее ведете, а от вас требует конкретные даты готовности, но вы не можете сами оценить примерный срок когда будет готово, попросите более опытных коллег вам помочь, так же письмом с назначением встречи, через календарь или другое средство которое принято вас в команде.
И в целом общий совет, старайтесь к любой встречи где будет техническое обсуждение, уже иметь для разработчиков или тех людей которым вы будите задавать вопросы, документ который можно будет предметно обсуждать, это может быть , спека(спецификация), ФТ( функциональные требования) ФД ( функциональный дизайн), диаграммы, ППР(протокол проектного решения)или простенький документ с буллитами вида :
описание
что сдаем
что нового в задаче
информация которую предоставил заказчик
о чем договорились с заказчиком
вопросы которые необходимо уточнить.
И тогда работать будет проще в любой команде. старайтесь не наседать на коллег звонками по 2 минуты( на самом деле они не идут 2 минуты), это тратить и ваше и их время.
�
О, да, совещания без подготовленного плана это как правило балаган в итоге, и без нормального результата
Спасибо за комментарий, сразу видно профессионала, с которым приятно работать.
сформулируйте список вопросов
Добавлю к этому: старайтесь накопить вопросы в течении некоторого времени. Если слать по письму на каждый вопрос, который возникает в вашей голове в течении дня - от вас быстро устанут.
не оптимистичные сроки, а пессимистичные
Золотое правило в IT. Ошибка планирования - это норма, но никак не исключение. Безопаснее считать, что ей подвержены все, с кем вы общаетесь.
старайтесь к любой встречи где будет техническое обсуждение, уже иметь {...} документ который можно будет предметно обсуждать
Однозначно.
Во-первых, голосовое общение без какого-либо визуального материала менее эффективно. Даже если вы расшарите пустой документ с двумя вопросами (кто виноват и что делать, хехе) - это поможет участникам сфокусироваться лучше, чем безжизненные аватарки, окно с которыми наверняка будет всеми скрыто и заменено на котиков и Интернета.
Во-вторых, это поможет участникам сразу погрузиться в контекст встречи.
Вообще, переключение контекста - очень важная проблема, которую зачастую игнорируют даже опытные коллеги.
Задавая вопрос, всегда нужно понимать, что контекст для этого вопроса может существовать только в вашей голове. Если вы зададите его "как есть" - вас могут либо не понять, либо потратить неслабые когнитивные усилия на расшифровку, когда можно было бы потратить те же усилия на непосредственно ответ. Даже если вы работаете вместе уже некоторое время, не помешает написать пару вводных: "я такой-то, занимаюсь тем-то для того-то".
Для многих специалистов их текущий контекст - это состояние потока. Для достижения этого состояния всегда требуется усилие. Если вы хотите получить мгновенный ответ на свой вопрос, стоит рассматривать это как следующую дилемму:
вы уверены, что специалист находится с вами в одном контексте, либо в контексте вопроса, который вы задаёте, тогда ответ не потребует от него потери фокуса;
ваш вопрос настолько важен, что ради ответа специалисту в любом случае нужно бросать текущий контекст и переключаться на новую задачу - редкая ситуация, буквально пожар на производстве.
Все остальные ситуации никак не укладываются в концепцию "наберу на две минуты" - вы просто разрушите рабочий процесс своего коллеги в угоду своему нетерпению.
За первый пункт +100500. Классический приём: письмо 10 адресатам с вопросом вида "Коллеги, что будем делать" или "коллеги, когда будет YYY". Естественно, все 10 адресатов молчат, потому что каждый думает, что спрашивают не его. Есть подозрение, что некоторые товарищи такое письмо применяют для ИБД: вроде как ПМ своё дело сделал, команду потеребил, а команда ни гугу.
Главный лайфхак - культура письма.
Коротко. Понятно. По сути. Важное - вверху. Зоопарк с цветами, шрифтами, капсом - не допустим. Одно письмо - одна тема.
А ваш пример "Прислать вам сроки" я бы тоже проигнорил.
Без обид, вы принесли проблему.
Надо потратить кучу времени на уточнения. Потом это посчитать. Учесть риски. Развернуто ответить.
А для чего? Чтобы в случае нарушения этих сроков вы жирным красным капсом переслали эти сроки всем руководителям, до которых дотянетесь?
Лайфхак: принесите людям пользу. Задумывайтесь о том, что людям нужно. Не приносите проблем, даже потенциальных. В корпорациях "ты мне - я тебе" отлично работает.
.
А ваш пример "Прислать вам сроки" я бы тоже проигнорил.
Вообще такой вопрос свидетельствует о полном непонимании того, что в програзме помимо "фронта работ - от забора и до обеда", есть ещё и риски. То есть, сроки, на самом деле - это некоторая случайная величина, которая уточняется по мере выполнения работ.
Тема просто песня)) Я ээ.. 16 лет работал в конторе, в которой несколько раз поменялся менеджмент и лиды. Плюсом был опыт общения с саппортом 2 крупных производителей техники. Все 16 лет нам говорили, что мы работаем в режиме 12 через 12 - те задачи которые у нас есть утром, надо сделать к вечеру, чтобы следующие 12 часов их решали на другой стороне. Ну и плюсом у нас тоже были и команды, и департаменты со своими задачами, но с общим конечным продуктом в продакшене. Так вот, пункты 4 и 6 работают, остальное либо нет, либо усугубляют проблему.
Про контрагентов - один реагировал на все письма, эскалировал когда надо внутри своей конторы, запрашивал эскалирования у нас, если это переходило на бизнес уровень. Второй (с золотым саппортом, причём) как правило тоже отвечал, но держал оборону) Потом я добавлял шефа, тот своего, доходило до наших CEO, мы покупали ещё, они фиксили.
Про отношения между командами локально - несколько групп у нас вводили расписание на общение с другими командами. То есть просто слали всех кто приходил в неурочные часы. Их можно было понять, но карму им это не повышало) В переписке они тоже считали возможным игнорировать вопросы о проблемах в их функциональности. Ну, это их выбор, эскалируйте их и вашему руководству и забудьте о этой теме вообще, пока не ответят. Спросят статус - перешлите тред с комментарием.
Из смешного - к нам в комнату часто ходили с вопросами из соседнего департамента, и часто они касались смежной функциональности. Как то раз функциональность оказалась вообще не наша и даже не рядом, на вопрос зачем и почему вы пришли с вопросом к нам нам ответили - вы с нами разговаииваете))
Я бы, наверное, кроме поддержки 4 и 6, дал ещё совет собирать все кейсы проблемных коммуникаций и когда спросят, а в нормальном процессе спросить должны, выдавать их в HR или кто занимается этими вопросами. Ну и найти кто отвечает)
Кстати, одного, кто любил спрашивать, чтобы облегчить себе жизнь, и не любил отвечать у нас уволили за неэтичность к коллегам.
Попробуйте все, что вы собираетесь спросить, сперва сформулировать в печатном виде. Перечитайте, осмыслите, внесите правки и ... занесите в список своих вопросов как задачи в трекере. А же потом можете воспользоваться "телегой" или телефоном.
Да-да! Попробуйте перевести диалог в трекер. Заодно базу знаний пополните ранее незафиксированными вопросами. А коллеги пополнят ответами, если им есть что сказать :) Во многих трекерах есть возможность "озадачивать" вопросом каждого адресата персонально и назначать предельные сроки ответов. Это нормально. И дает факты при разборе полетов на тему "кто", "кому", "что" и "когда" был должен и чем помог.
Не стесняйтесь вести такой трек. Не стыдно не знать, стыдно не спрашивать и не фиксировать ;) Ремесло аналитика в том и заключается, чтобы вытаскивать из гениальных голов содержимое и делать его достоянием коллектива. Нравится это кому-то или нет.
Красная паста и крупный шрифт. Такой простой трюк добавляет значительной агрессии письму, и оно точно привлечет внимание. Выделять красным только самое важное. Осторожно: такое письмо способно взбесить, особенно если вопрос действительно глупый. Но ответ придет обязательно.
У меня была коллега, которая любила использовать такие вот шрифтовые изыски + навесить приоритет и напоминалку на письмо - все закончилось тем, что большинство потенциальных адресатов её писем настроили правила в аутлуке, очищающие письма от подобных "украшений"
- Подскажите, пожалуйста, по срокам смежников
- Да
В каком то роде хорошая статья. Если спустя время сможете поделить на ноль свое собственное правило коммуникации, тогда это будет яркий индикатор профессионального роста.
Для начала выражаю искреннее поздравление автору: первая статья на Хабре залетела с ноги и подняла такое бурное обсуждение! Уух!
Я, системный аналитик с общим опытом 6 лет на банковских проектах, сталкивалась с такой же проблемой, когда была джуном, поэтому решила поделиться своим опытом ниже.
На самом деле накал страстей в коммуникациях зависит от самого проекта: на каких-то проектах все коллеги идеально последовательны и нет никакой напряженности, и ответы не надо выбивать, но вот где-то просто мрак (вот вроде и договорились, и письма о сроках есть, но вот реальных дел нет, - и эти проекты самые зубодробительные).
Каждый новый случай молчания со стороны коллег - это новый челлендж, и обычно он упирается в задачу "Выясни причину молчания и предложи такое решение, чтобы выиграли обе стороны обмена информацией". Посмотри на это с системной точки зрения: ты - сервис А, а твой получатель - сервис Б, сервис А запрашивает у сервиса Б информацию, но в ответ получает ошибку по таймауту. Как решить эту задачу?
Мой подход на текущий момент (сорри, буду уходить в подробности, чтобы подсветить все острые углы, которые всплывали походу письма):
1) Понять формат работы своих коллег. Например, если сроки горят у всех и все перерабатывают, то, наверно, не у всякого будет время вчитываться в письма. Люди просто могут не открывать почту, чтобы успеть сделать тот пул задач, который запланирован в их спринте. Или же другая причина: разработчики просто не пользуются почтой, потому что задачи им ставит аналитик или манагер (зачем пользоваться ненужным инструментом?!). И это классика, и с этим надо считаться, поэтому всегда уточняю формат работы смежников, даже если работаешь с ними в одной крупной компании, формат взаимодействия с почтой/мессенджерами может отличаться у других команд. И иногда получается интересная ситуация: ты пишешь письмо, а оно не дошло до адресата, т.е. письмо ушло в никуда. Некоторые мои коллеги ставят ещё функцию "уведомить при прочтении", чтобы снять этот риск, но я этим не пользуюсь, хотя ничего против этого не имею.
2) Написать информативное письмо
Это целое искусство и этому надо учиться (я не читала книжки на эту тему, училась у коллег "по подобию", но наверняка уже много полезного издано): пишешь коротко/информативно, убираешь канцеляризмы (Ильяхов в помощь и этот навык нарабатывается с опытом), ставишь Имя и выделяешь жирным, срок само собой или просьбу к получателю сориентировать по сроку. Если не знаешь, к кому обратиться - иди к PM, а он сориентирует, не знает PM - к лиду. Поиск ответственного иногда тоже тяжкая задача и тут надо быть готовым перелопатить половину отдела, потратить на это дни, чтобы найти этого "ответственного".
Красный цвет не использую совсем (только крайний случай, когда ничего не работает, и по согласованию с PM/PO). По мне это агрессивно изначально, потому что вопрос не приобрёл такой статус, чтобы сходу агрессировать на получателя. Я думаю, что красный у всех ассоциируется с ошибками в школьных тетрадях, и поэтому у этого цвета в письме априори негативный оттенок: вот ты только получил письмо, а уже в чём-то виноват; ещё ничего не сделал, а уже где-то ошибся. Как решение, использую форматирование: жирность, курсив, буллеты или нумерацию - это менее агрессивно, но подчёркивает именно те мысли и те слова, за которые будут цепляться мои коллеги. Если письмо важное, есть метка "Важно" у письма - так было в аутлуке. Если же PM настаивает на красном - ууух, кажется, мы переходим в абьюзивные отношения с коллегами и это нехороший знак... Я как-то на старте своей карьеры читала книжку про шрифты и их форматы и была в полном восторге, как за счет шрифта передать скрытые смыслы через форматирование ("О шрифте", автор Эрик Шпикерманн - может кому-то пригодится).
Важно помнить, что моя задача, как аналитика - сэкономить время на прочтение моих "опусов", поэтому лаконичность и краткость наше аналитическое "всё". Я отмечу ещё, что важно также ставить в подписи к письму "С уважением, Имя Фамилия", а не просто "Имя Фамилия". Вроде бы замыленный стандарт по-умолчанию, но меня, как человека, который постоянно читает деловые письма, всегда коробит подпись без уважения. «Ты приходишь и просишь что-то у меня, но ты просишь без уважения», да-да-да, именно эта мысль и приходит на ум.
3) Что делать, если не отвечают на вопросы
И вот письмо написано вроде бы идеально и нужным людям, но игнор... Первое, что приходит на ум - письмо не прочитали. Решение: ищем мессенджер коллеги и пишем ему нейтрально "Здравствуйте, я такая-то, писала Вам тогда-то с таким-то вопросом. Вы видели моё письмо?" - далее пытаюсь выяснить причины задержки с ответом (опять же нейтрально, с желанием искренне помочь наладить коммуникацию).
Идём по негативным сценариям и обычно причины такие:
а) я не читаю почту, сейчас открою и посмотрю;
б) я этим не занимаюсь, но у меня было много своих задач, чтобы сообщить об этом в ответном письме;
в) у меня много задач, иди к моему манагеру за выделением ресурса.
Дальнейшие шаги по кейсам:
а) договариваемся о дальнейшем формате взаимодействия, чтобы в дальнейшем не задерживать ответы (см. 1 пункт про почту и загруженность): i) можем ли обращаться по мелким вопросам или обращаемся всегда к манагеру команды, и ii) потом обязательно информируем своего манагера о формате взаимодействия, потому что он может подсветить риск, что "так не пойдёт, надо обязательно общаться в почте и никак иначе";
б) пытаюсь дальше найти реального ответственного через PM/лида;
в) иду к своему манагеру, чтобы он "на манагерском" объяснил другому манагеру о включении вопроса в пул задач нужного мне человека. Ошибка здесь: уговаривать ответственного быстро посмотреть вопрос, если ты и твоя команда не знает формат взаимодействия с этим человеком или по каким-то причинам нужно именно с этой командой "всегда и всё фиксировать в письмах". Это деловое письмо, и нужно делать всё чисто, т.е. без скрытых потерь времени со стороны получателя, иначе это может вылезти в неприятный выговор лида/PM к аналитику. Думаю, что выговор рождается так - манагер на дейли спрашивает X: "Почему ты не сделал то-то?", X: "Ну мне там написала вот такая-то, я целый час смотрел, как оно работает и потом думал, как объяснить", манагер: "Ясно-понятно, поговорю с таким-то, чтобы все вопросы решали через меня и никак иначе, у нас сроки горят, а они отвлекают..." Я не раз на это наталкивалась: и вроде бы с душой к человеку и он к тебе с душой отвечает, а по факту жестокая реальность разбивает эти душевные отношения.
4) Немного слов про зубодробительные проекты
Был у меня проект в синем банке давно ещё, до трансформации, где в одни из моих обязанностей, как аналитика, как раз входило выбивать сроки и следить за договоренностями всех сторон. Эдакий "коллектор" в мире банковского IT. Опыт незабываемый: постоянно держишь руку на пульсе, когда истечет срок дачи ответа, чтобы начать эскалировать и подключать руководителей подразделений (иначе ай-яй-яй, ты не выполняешь свои обязанности, как аналитика). У тебя инструкция от своего лида, как действовать в таких ситуациях, и ты действуешь чётко по инструкции - подключаешь руков, каких-то стейкхолдеров, о которых ты вообще ничего не знаешь, и постоянно пишешь эти бесконечные письма... Я по началу бесилась (ну как так?! только мне надо и больше никому?!), а потом смысл этих вопросов пропал, т.к. проблема в том, что на проекте не налажен комфортный формат коммуникации между подразделениями, и (главное!) это не моя вина. Что здесь можно сделать, если такой формат превратился в паттерн? Правильные действия - это эскалировать, т.е. поговорить со своим менеджером или лидом и спросить, можно ли поменять ситуацию в лучшую сторону, потому что эти непродуктивные коммуникации влияют на сроки проекта, твоих задач и мотивацию. В моём случае формат коммуникаций чуть улучшился (не из-за моей эскалации, а потому что проблема была явно видна всем без эскалаций), но не стал идеальным; проект запустили, но моя злость к нему осталась. Надо всегда держать в уме, что такие проекты, где руководство по каким-то своим причинам не может организовать каналы коммуникаций, 1) влияют на твою самооценку и отношение к текущим и, возможно, к будущим коллегам 2) дают тебе возможность прокачать свои скиллы. Я оставалась на проекте, потому что училась у других стрессоустойчивости и решению конфликтных ситуаций, написанию писем и ТЗ, работе в команде. Потом уволилась, т.к. нарастила нужную мне экспертизу и оставаться уже не было смысла (получаемый негатив перетягивал позитив).
"Сейчас я переписываюсь и решаю все вопросы по новым интеграциям максимум за 2-3 дня. За исключением тех моментов, когда смежники - совсем занятые ребята. Пока не придумала, как до них достучаться еще быстрее. Что посоветуете?"
Выезжайте на объект за ними! ?
Спасибо! Возьму на вооружение советы, кроме выделения красным цветом, уж больно радикально на мой взгляд.
В статье всё написано правильно и по делу. В условиях удаленки достучаться до людей стало ещё сложнее, чтобы выудить нужную информацию.
Вся беда в том что люди, негативно отреагировавшие на статью скорее всего попытались спроецировать это на свою компанию/отдел/проект. Поняли что им это не вяжется и начали возмущаться. И это действительно нормально негодовать когда на вашем тихом проекте приходит кто-то и начинает вводить свои новые порядки. Но, как известно, ситуации бывают разные.
Помните всегда главное, цель команды успешно выполнить и запустить проект, работать как единый механизм. При необходимости доставать из коллег информацию пассатижами, да, приходится прибегать порой не к самым чистым методам.
Использовать "Теги", которые есть в Outlook - да не, бред. Уведомления о доставке и прочтении - так же бред.
Что посоветуете?
Для начала, в случае игнора на первое письмо - использовать фишки почты, о которых написал выше. И использовать правильную нумерацию, ибо у вас один пункт пропущен:
Конкретика. В письме не должно быть воды. Вопросы должны быть простыми, понятными, без додумываний, двойных смыслов и т. п. «Подскажите по срокам» — это непонятно, т.к. можно подсказать «адекватные ли сроки», «уложимся ли мы в них», «будет ли готово день в день или раньше» и т. д. Конкретный вопрос — залог успеха. Простой конкретизированный вопрос - проще дать ответ сразу. Сложный вопрос с неопределенным смыслом - надо обдумать и потом как-нибудь отвечу.
По остальным пунктам уже критика:
Да
Бред. Почему именно 2 минуты? У меня может не быть сейчас 2х минут на болтовню с кем-либо. У меня может вообще не быть времени на разговоры с этими "эээээээм, амммммммм, хммм". Так же полностью нарушает первый пункт - на тему чего разговаривать то собралась? Видео с котиками обсудить? Может разговор затянется, т.к. к вашим вопросам необходимо подготовиться, подняв кипу документов или задач. В 99% случаях подобные запросы на "беседу" будут игнорироваться. Кроме того, устный ответ - это ответ без явного подтверждения, так что все равно будете повторно запрашивать ответ в письме, т.е. придется делать двойную работу и тратить заметно больше времени.
Это добавляет плюсов в пользу нежелания с вами общаться. Стандартные способы выделения - полужирный, курсив и подчеркивание - ничем не хуже, при этом вызывают меньше гнева и никак вообще не страдают от настроек почтового клиента или ОС.
Первый раз просто пишете письмо человеку, от которого нужен ответ. Второй раз пишете такое же письмо с тегами "важно, срочно и т.д.". В третий раз уже добавляете руководителей. Если сразу добавляете руководителя - идете нафиг, еще и руководитель подкинет пару крепких слов для ускорения движения в заданном направлении. Исключения - прям очень срочные письма, но такие встречаются крайне редко.
Есть ощущение, что вы не понимаете куда вообще надо писать и пишете случайному разработчику команды, которая ответственна за задачу. В первую очередь необходимо найти к кому непосредственно обращаться.
Дефолт
Никак не влияет.
Рабочее письмо - это не курсовая, нир или вкр, тут не нужно воды вообще. Максимально кратко и понятно описали что вам нужно - получили ответ. Налили воды - ваше письмо будет в числе последних, на которое будут тратить свое время.
Очень интересно читать коменты, сразу видно, кто есть кто. От себя могу лишь добавить свою схему, как приручить технаря:
Пишу письма только для того, чтобы закрепить где-то договоренности, чтобы в случае эскалации было, куда кивать. В почте почти всегда или игнорщики или двиерсанты, который могут написать отказ, "мол не будут они это делать"
пишу в мессенджеры, чтобы обсудить детали, но не бесить людей лишним вниманием, ясно же дело, что разработчики и прочие технари не любят, когда к ним стучатся не вовремя.
Если не выходит договориться письменно в чате - я назначаю звонок на 15 минут в слот, удобный технарю. Отказать голосом (а еще лучше перед камерой) ему будет сложнее, чем письменно.
Если можно подойти в офисе лично, попросить - это прям лучший вариант. Лицом к лицу почти все - сладкие котики и соглашаются выполнить просьбу гораздо проще и быстрее.
Но все выше описанное не значит, что нужно сразу начинать с пункта 3-4, т.к. тоже рано или поздно начнут посылать, если не идешь по скрипту, а сразу расчехляешь тяжелую артиллерию.
А сами быстро отвечаете на письма от "технарей"?) Потому что у меня большинство проблем было с очень занятыми на удалёнке PM.
ПМы действительно заняты, очень часто на созвонах. Но да, вы правы - проблемы к коммуникацией порой случаются в обе стороны.
Работа ПМа - не бесить технаря, а сделать его работу максимально комфортной. важно - чтобы обе стороны это понимали и не стреляли себе же в ногу
Мне кажется это в компанейских стандартах должно быть описано. У нас было два филиала, в нашем было требование отвечать в течение суток либо полностью, либо со сроками полного ответа, либо отправлять куда то дальше. Во втором в связи с текучкой этого требования не знали и не хотели вообще признавать, что проблема есть. Так что пришлось и в копии ставить, и ретранслировать начальнику неотвечающего, и таски блокировать запросами, и треды собирать. Небыстро, через hr и топ менеджмент ситуация на некоторое время выправилась.А потом снова текучка на той стороне и снова очень много крайне занятых PO, PM, манагеров и прочих.Бескультурье, вообщем)
про 4 пункт плюсую. Но мне вообще априори кажется странным, если коллега через 2 ряда сидит, сначала писать ему в мессенджеры. Я сразу подхожу и спрашиваю, удобно ли ему переговорить со мной по такому-то вопросу.
Блин, от человека, который пишет в мессенжер еще есть шанс отвертеться, выключив мессенжер. (на время сосредоточенной работы) Но от подходящего так не скрыться. Вы хоть понимаете, что спрашивая "удобно ли говорить" вы уже начали разговор, и задавать вопрос об его удобстве - поздно.
Ваши слова говорят о том, что есть проблема с отстаивнием своих здоровых границ. Выключая мессенджер и проч. Вам неудобно отказывать людям, говорить «Нет».
Если ко мне человек подходит не вовремя (спросит он удобно ли мне-не спросит, мне все равно), я ему прямым текстом скажу: «я сейчас занята тем-то и тем-то, давай поговорим через 20/30/40 минут».
Вы, очевидно, не понимаете насколько ресурсозатратная работа это наше программирование. Попробуйте на досуге.
Ну или представьте, что к вам подошли, когда вы собираете кубик Рубика, или играете в шахматы, пытаясь продумать 5 ходов вперёд. Не знаю ещё какие аналогии привести, мб в комментах накидают.
Вообще, есть классическая иллюстрация:
Я могу послать устно. Но это будет поздно и [в данном эпизоде] бесполезно. Хотя если послать с нарушением комплаенса, то это может помочь в будущем. Но это дорого с т.з. ревью по софт скилам.
Для вас специально написали:
выше описанное не значит, что нужно сразу начинать с пункта 3-4, т.к. тоже рано или поздно начнут посылать
Но до вас никак не дойдёт.
Несмотря на "как приручить технаря" - очень адекватный комментарий, спасибо.
И отдельно хочу заострить внимание на "не идешь по скрипту": ваши действия должны соответствовать степени важности вопроса. Подойти лично должно быть крайним средством, иначе после нескольких раз эта стратегия потеряет свой вес: технарь научится делать рожу кирпичом и говорить, что он очень занят на ближайшее столетие, а то и вовсе негативить - такого никому не надо.
спасибо, там естественно не было цели кого-либо задеть.
Важно понимать сособенности и работы и личности человека по ту сторону :)
еще 2 поинта:
весь мой скрипт и все способы контакта отлично подходят под условного тим-лида, или человека, который уже явно назначен на задачу и находится в контексте.
если человек не в теме и не знаком мне в принципе - идти к его столу и задавать вопрос - весьма плохая тема. (Впрочем, писать письма, когда вы сидите в паре метров друг от друга - тоже довольно фрустрироующая тема)
было дело. Ко мне ПМ один постоянно в процессе работы с вопросами подходил. А я в этом плане человек вспыльчивый, на попытку оборвать рабочий процесс могу и на три буквы прямым текстом послать. Работал он не долго
Больше похоже на манипуляции, а не на менеджмент
За 3 дня: 166 комментарий, 70+ закладок.
Вы явно задели людей за живое :-D
Я вот корпоративную почту читаю примерно никогда. Потому что в мессенджер написать и ответить в 10 раз быстрее. Если срочный вопрос - пишешь в личку и спрашиваешь, случаев что проигнорили было около 0%.
И сложилось такое впечатление, что автор борется с системой в лице некоторых людей и всеми силами старается их победить. А не надо пытаться никого победить, надо работать с людьми. Не надо быть злобной тёткой, которая заваливает всех письмами с постоянным дёрганьем руководителей и красным текстом капсом - это корпкультура явно не айти компании, а бухгалтерии постсоветском завода в худшем смысле.
А мне статья понравилась. Все о чем Вы написали я в той или иной мере встречал, и это реально работает. Не скажу по поводу именно Вашего кейса, но я с этим столкнулся в компании, где был КОЛОССАЛЬНЫЙ техдолг, отдельно взятые токсичные коллеги и, конечно, неэффективные процессы, само существование которых сильно препятствовало внедрению новых, более простых и эффективных процессов. Приходилось по-сути выживать каждый день. И указанные Вами методы, как и некоторые иные, весьма мне помогали.
Верно, и тут имеется ввиду - пишешь письмо кому-то конкретно, а в копию можешь ставить уже других лиц, в т.ч. своего руководителя и руководителя того сотрудника, кому пишешь.
Согласен, обязательно так и только так! Чем больше живого общения голосом или даже с камерой - тем лучше! Только всегда, всегда, всегда нужно ронять позитив ) ну а если коллега совершенно токсичен - с ним лучше без камеры и позитива, но все равно - голосом и вежливо!
Да, и только в самых редких случаях красная. Можно использовать синий жирный, это даже более заметно и не напрягает никого.
Я вообще когда работал, руководитель говорила - меня ставь в копию всех своих писем. Странно, конечно, было, но в чем-то и понимаю этот момент.
Ну, чтобы не было бесконечной адресации за каждый процесс должен быть ответственный. И пусть он переадресует что хочет, кому хочет, как хочет. Его проблемы уже, если не сделает качественно и в оговоренный с ним самым срок.
Все четко и верно написали. По итогам каждой встречи должно быть краткое резюме с итогами встречи и назначением ответственных лиц, сроков и т.п.
Вежливость да, должна быть. Я пишу "пожалуйста", если о чем-то прошу любого человека, который не является моим подчиненным. В 90% приходится писать там, где люди должны делать свою работу, и не сделали, потому что не выстроены/корявые процессы. Ну, мне не трудно. И даже в радость это писать коллегам, которые не гордые, позитивные, доброжелательные.
Мне статья понравилась, жаль, не могу добавить Вам кармы, потому что свою где-то порастерял. Не обращайте на разные комментарии здесь - Вы на верном пути!
Игнорят, значит, поднимаемые вопросы не важны. Или ваша работа не важна.
Важные и нужные вопросы не игнорят.
Меня почему то не игнорят. А если игнорят, то есть хорошая пословица:
"Не мешай другому обосраться".
Читаю комментарии - ой, я почту не читаю вообще, ой, что это за формат общения не корпоративный, ой, гори в аду... Тоже мне..
Делаю так. Первое письмо с указанием сроков ответа, что то типа - Barrybarry (если людей много в письме, без уточнения имени каждый подумает, что не ему), сообщи(те), пожалуйста, сроки до конца недели (или какой-то нужный срок). В копию руководителя его/общую группу команды человека/коллегу из его команды, кто тоже может обладать информацией.
На следующий день после окончания срока пишу что-то типа - есть новости? Когда сможете сообщить? Если тишина ещё пару дней - и ещё в личке игнорят (или должность не очень позволяет в личку стучатся). И лучше всего ещё добавить своего руководителя. К сожалению, часть коллег априори не хотят общаться без руководства в копии письма (с чем связано - хз, но часто встречала это).
Снова тишина? Ну ок, планирую звонок на 15 минут. Если тотальный игнор - эсколация вопроса через руководство.
Прежде всего стоит наверное сказать, что сейчас общение по почте для разработчика скорее редкость, т.к. все общаются в мессенджерах, так банально быстрее. И письмо в почте от живого человека, а не отбивка из Jira, это уже привлекает внимание.
Логично. Если я письмо пришло на группу людей или вопрос кинули в общий чат, то я даже не обращаю на это внимания. "Кто-нибудь другой ответит". Такова правда.
Почти 100% гарантия результата. Для этого мессенджеры и используют. Единственное, это могут не любить всякие синьёры, которых все дёргают. А тут ещё и джун с глупым вопросом лезет. Лучше сначала письменно обозначить свой вопрос, а потом предложить обсудить. Может и звонить не придётся.
Это раздражает, да. Лучше не стоит. Если это важно, максимум - красный восклицательный знак у письма.
Так не делают внутри компании с нормальной атмосферой. Руководителей всех мастей ставят обычно в копию при общении с заказчиком, чтобы было документально подтверждено у всех о достигнутых договорённостях и прочее. А если внутри компании нужно ставить руководителя в копию для подстёгивания ответа - это какая-то нездоровая атмосфера.
Руководитель "смежников" должен знать. Если вопрос затягивается, в первую очередь надо идти к нему. Обычно, в такой ситуации собирается созвон, на который руководитель подтягивает того, кто может разбираться в вопросе, если сам он не в курсе. И всё решается за пол часа.
Очень официально) Но имеет место быть. Где-то) Я уже давно не сталкивался с протоколами встреч. Наверное потому, что я всего лишь разраб, которого волнует только код) Мы не участвуем в таких встречах.
О да. Излишняя вежливость бросается в глаза. Хотя вот совсем без неё тоже плохо. Это ты пишешь нейтральное письмо типа "Пришлите сроки по задаче..." или "В каком статусе сейчас задача...". А человек на той стороне может неправильно считать эмоции с такого письма и подумать, что на него наезжают. Да, бывают такие люди)
Лучший рецепт - писать в корпоративные мессенджеры что-то вроде: "Привет, наберу на 2 минуты?"
Кого как, а лично меня вымораживают такие мета-вопросы. Уже же написали и даже в личку либо поставили триггер, если в общем чате. Пишите сразу чего хотите и там обсудим нуден ли созвон. Зачем сразу звонками-то отвлекать? Понимаю, Вам нужно работу работать, но лично для меня приоритет всегда на мою работу и лично меня подобные сообщения и, тем более звонки, выбивают из колеи, после чего становится сложно собраться, вследствие чего страдает продуктивность. Вдобавок, есть свой пул задач и если вопрос не связан с ними…
Хуже этого был в моей практике случай, когда мне позвонили по телефону сказав «Зайди ко мне через 5 минут», а когда я пришёл, сказали «Твой вчерашний счёт на компьютер оплачен, можешь ехать забирать»…
А «красная паста»… Пару раз мне написали и потом я её просто перестал замечать в каком-либо виде, проигрывая в голове мысль «опять эта полоумная херню придумала да работать мешает».
И, к слову, почта штука такая что её далеко не всегда и не сразу проверяют. Лично я проверяю корпоративную почту один раз в сутки в начале рабочего дня. Чаще просто не за чем ибо это уже будет неоправданная трата рабочего времени.
Удивительно, сколько народу, судя по комментариям, живёт в коммуникационном аду. И сколько миллиардов человеко-часов компании жгут впустую из-за того, что информация не перетекает свободно внутри. Прям сильно расстроил Хабр.
«Коллеги, пришлите сроки!» — повторял джун-аналитик в течение месяца…