Pull to refresh

Comments 22

Очень многие не могут нормально рассказать на синкапах чем они занимались.

Просто "решали проблемы, отвечали на звонки, закрывали джиры". При этом смысл синкапов полностью теряется, поскольку они не делятся с командами тем, что изменилось в инфраструктуре, какие интересные кейсы были решены, что вообще происходит в компании.
А все что для этого нужно, просто завести себе какой-то report.txt или todo.txt и записывать в него пару предложений когда решаешь/решена проблема. и Потом на синкапе в него заглянуть и рассказать.

первый коммент и сразу в точку! Что ты делал? Я работал... Если отчетный период еще и большой, например, месяц, конечно надо записывать, что сделали или иметь систему хранения задач, где можно свои труды посмотреть.

Или это говорит о том, что вы требуете из рутины сделать эпичное фентези на стендапе.

А я пожалуй соглашусь с предыдущим оратором. Потому что вот это вот "я работал" оно абсолютно бессмысленно. В общем-то предполагается что ты работал. Тебе именно за это "я работал" деньги платят.

Но если на синкапе кроме этого больше нечего сказать, то тогда вообще ничего говорить не надо. А если всем кроме этого нечего сказать, то и синкап такой никому не нужен.

То есть на всяких personal review(или как они там ещё называются) надо начальству рассказывать что ты действительно работаешь и как хорошо ты это делаешь.

А на синкапах людей интересует не сделал ли ты что-то такое, что касается их работы. Что-то, что им помешает или поможет. Или наоборот может тебе от кого-то помощь нужна.

Так предыдущий оратор не говорит ничего предметного. Критикует — но не предлагает. Возможно, даже не пытается задуматься, а надо ли о чем-то докладывать специально, для галочки.
Его сентенция может быть как праведным гневом, так и жалобой симулятора занятости на то, что ему не дают повахтерить, но вы уже заранее солидарны.

Да вообще-то вроде предлагает. "report.txt" и так далее...

Нет.
Он предлагает решать проблему как заставить сказать больше двух слов на фентезийном стендапе вместо что говорить на синкапе, если сказать нечего, да и нужен ли был этот синкап?.
В отличие от него, последним вопросом вы задались, но не ясно, осознанно ли.

Такое впечатление что мы о разных комментариях говорим...

Нет, но о разных вещах.
Этот говорит о том, что осталось за кадром комментария. О неполноте создаваемой им картины, и о существовании других объяснений, приводящих к той же самой наблюдаемой картине.
А вы, кажется, о том, что у вас такая же нога и болит так же — что безусловно не плохо, но не дает больше информации, и не закрывает пункт выше.

Нет, из рутины я пытаюсь сделать полезную задачу - ввести коллектив в суть изменений на проекте. А просто отчитаться о сделанной задаче я могу закрыв джиру. Синкап то не для того придумали.

Давным давно, когда я работал в странной конторе (был молод, боялся уйти), в какой-то момент начальство не очень понимало чем я занимаюсь, и потребовало каждый день составлять подробный отчет. Отмазаться было нельзя.
Пришлось каждый день его писать. Месяца два так писал, в результате получил повышение в ЗП и в должности, потому что оказалось что много делаю. Ну и потом сказали что больше не надо писать, лучше это время на работу потрать.

Но за эти два месяца прошел все стадии - неприятие, гнев, смирение, интерес, творческая оптимизация процесса, поиск выгоды. Опыт успешный.

Я бы его джунам давал, пока у них времени полно, чтобы "самоорганизованный" не просто так в резюме писалось

Тогда, выходит, что вы знакомы с проблемой с обоих сторон.


Собственно, а что выходит не так в процессе?
Вот планируется фича, затрагивающая работу других коллег, из-той же команды, или даже из нескольких. Она наверняка обсуждается с менеджментом, ПМ, ментором/старшим/лидом (если есть) — не из головы же ее работают. То есть, без и отдельной речи обмен необходимой информацией уже произошел, изменения задокументированы, заинтересованные стороны оповещены заранее. В процессе работы наверняка происходит коммуникация между членами команды и между командами — народ должен быть в курсе. Остается аппрув и вливание в основную ветку.


Вопрос, а для чего тут нужна речь — напомнить, что мы, вообще-то зарелизили фичу с ломающими изменениями? Так целостность и согласованность это обязанности других, и для этого есть инструмент аппрува…
Что должен сказать выступающий, когда все сказано до него?

Ну например я хочу пойти в отпуск. Я сделал какое-то исправление. И ушел в отпуск. Тот кто будет меня замещать - было бы неплохо чтобы он был в курсе что я делал хотя бы в общих чертах. И если что-то пойдет не так - он быстро разберется.

Не все вещи можно в пулреквестах быстро понять, там только код.

Понимаемо.
Но рассказанное забудется, а документация — останется, даже если все уйдут.
Не говоря уже о том, что фиксы перед отпуском это из разряда релизов в пятницу вечером.

Заметил тоже самое в команде. Вроде все что-то делают, а на синках складывается впечатление, что ничего конкретного. И тут я наткнулся на статью о документ-ориентированных совещаниях в Amazon

Теперь за 30 минут до планёрки в слаке создаётся трэд "Что делал вчера, что будешь делать сегодня". Соответственно туда пишут заголовок (клиент, что надо было решить) ссылку на jira-задачу, на какой стадии (если ещё не решил задачу). Если решил - просто ставят галку. На а на синках разбираем коллективным разумом моменты на которых кто-то застрял и не понимает, что делать дальше или если что-то интересное встретил в процессе.

Я по характеру скромный и много говорить не люблю, так что пришлось в своё время «ломать» себя, чтобы научиться правильно отчитываться о работе. Особенно если людям, далёким от IT вообще или твоего стека в частности. Если вкратце:

Плохо:
Готово
Лучше:
Сделал то-то и то-то
Именно сделал, а не «само сделалось». Иначе прозвучит, будто всего пару кнопок нажал и пошёл смузи пить, а назавтра сообщил о готовности.

Плохо:
Поправил загрузку файлов
Лучше:
Разобрал имеющийся код загрузки файлов и нашёл кучу багов и потенциальных уязвимостей, в итоге большую часть переписал с нуля и добавил проверку на целостность архивов rar, zip, 7z, tar.gz
Лучше писать как есть, никто за тебя додумывать сложность работ не будет (а уж тем более вчитываться в код). Плюс, люди будут знать, что тестировать.

Плохо:
Проблемы исправил / Больше багов нет
Лучше:
Потестил так-то и так-то, больше багов не встретил
Вообще любую фразу по рабочим вопросам нужно формулировать как точный, подтверждаемый факт. По той же причине, по которой в описи имущества не пишут «золотое кольцо», а пишут «кольцо из желтого металла проба 383» — потому что если кольцо вдруг окажется не золотое, то будет проблема. Так же и с отсутствием багов — если вдруг обнаружатся ещё баги, то фактически получится, что наврал. Могут потом ещё долго припоминать (и хорошо, если в шутку).

Ну и куча всяких мелочей про использование подходящих синонимов. Вместо «не успел» лучше сказать «не хватило времени». Вместо «налепил кривых костылей» — «пофиксил по-быстрому». Вместо «не знаю» — «затрудняюсь сейчас точно ответить». Смысл тот же, вранья нет, а звучит намного лучше.

Плохое решение — позиция «Я хвастаюсь»‎: 

«Я работаю в техподдержке уже 30 лет, за это время решал самые разные кейсы и общался с главными топами сферы. Поэтому лучше знаю, как нужно работать!»‎

Хорошее решение — позиция «Я делюсь»‎: 

«За 5 лет моей работы в компании оценка удовлетворенности клиентов выросла с 7 до 9. За это время я решил более 500 B2B-кейсов, благодаря мне и команде около 10 клиентов вырастили свои мощности у нас более, чем на 40%»‎.

Честно говоря, я бы больше зауважал первого чела. "Оценка удовлетворённости клиентов с 7 до 9" – это какой-то развод.

Вот прямо чувствую сейчас удовлетворённость 7. Может быть даже 7.1.

Думаю, тут речь про конкретную метрику «удовлетворенность пользователя», которая формируется на основании опроса пользователя (привет, система менеджмента качества и исо-20000), а не про ощущения работника.

Естественно, речь про метрику, но вопрос в том, что в действительности отражает эта метрика и как это связано с ощущениями пользователя сейчас и 5 лет назад. И уж тем более - как это соотнести с работой конкретного человека.

Статья хорошая, и у вас конечно симуляция для примера, этот выбор между Сашей и Петей. Но в жизни я вижу несколько другой расклад.

Презентационные навыки, это скилл который надо поддерживать и развивать, но для некоторых категорий Саш и Петь это противопоказано. Достаточно того, что они просто репортят что они делают, но это делается просто организацией их труда. Этим занимается их начальник. Просто потому, что их квалификация и их работа намного дороже, если они будут занимать своё время чем то ещё, кроме этой работы. А презентация своей работы, это дополнительные затраты времени, отнимаемые у высококлассного специалиста.

У нас тоже когда-то, когда контора "поднялась", начали учить всех и вся. Ну и вышла эта бесконечная презентация, организация процессов на низовом уровне, правильные подачи материала и не просто репорты, а красивые репорты, бесконечные репорты.

В итоге на верхушку со временем прошли только бла-бла балаболы, ну и специалисты подразбежалтись, какой смысл там сидеть, если не ценится, что они делают?

Поэтому с точки зрения руководства, я бы не выплескивал ребенка вместе с водой. Ну а презентационнные навыки конечно важны.

Когда в команда открывается позиция тимлида, Саша проигрывает коллеге Пете.

А может Саше не нужна позиция тимлида? Это совсем другая позиция - это организационная работа и работа с людьми. Знание и понимание продукта это как бы всё из другой области. Меня всю жизнь пытались задвинуть на руководящую должность только потому, что я знал своё дело и делал его хорошо. Но с неумными людьми я не дружу, так что нафига мне эта руководящая должность?

Пытался вспомнить хотя бы одного руководителя, которого назначил за красноречие - не осилил.

А что делать, если презентовать себя могу, а тимлидом быть не хочу?

Нравиться работать одному, или хотя бы в некоторой изоляции с четко прописанным workflow.

Sign up to leave a comment.