Comments 21
от разработчика до руководителя! я был никем и стал важным боссом))))
вы и не менеджер и не аналитик и не архитектор, а так, обычный "манагер".
требованиями и в том числе бизнес, пусть занимаются аналитики, архитекторы пусть занимают на чем и как писать код. а вы поймите что руководитель проектов это другое направление деятельности в отличии от разработки и займитесь своими задачами, хотя бы узнайте зачем вообще РП нужен))
Жестко)
Почему откровенное хамство набирает столько плюсов? Вот вам и хабр
Я рад, если моя статья помогла вам выплеснуть энергию внутри и вам стало от этого лучше/легче
Если отвечать на ваш комментарий, то мне непонятно как вы смогли сделать такой быстрый вывод обо мне, прочитав только одну статью
а кто сказал что мне стало лучше\легче? это называется - Демагогические приёмы.
я тоже могу так сделать: "вы не рады, вы пытаетесь выпутаться из того что вас .... блаблабла".
видите, я сказал утверждение, сам объявил его истиной и на нем построил дальше предложение. так делать плохо ;)
как я сделал вывод? ну у вас в профиле написано что вы ментор РПшников в ИТ, канал вон свой ведете. пришли со статьей не реальных кейсов, а скорее со "стратегией". А значит хотите задать вектор для юных умов, т.е. джунов.
почему жестко ... потому что вы в первом же предложении в целом, то обидели разработчиков (ни некрасиво это писать от <должность> до <должность> ... вы поставили сразу себя на ранг выше, хотя это разные профессии вообще-то). Ну а во вторых такие статьи портят и без того ОЧЕНЬ скудным мир толковых руководителей, тем что на старте их отправляют туда, куда лучше не ходить и в целом рисуют им корявую парадигму.
ну и потому что видимо неделя такая на хабре "стратегов" писать статьи "флаги", прибежали, помахали, думали плюсами закидают? нет, тут иногда и покритиковать могут. вы как говорил один мой друг просто "не в профессии". но увы таких основная масса в мире РП (( вот такая печалька))
имхо, вы видели статьи про докер стратегические?)
ну так уместите стратегию свою в пару абзацев и просто поделитесь опытом в статье на конкретном примере что и как делали. как вы выбрали архитектуру когда разраб джун был, откуда у вас был опыт пул или пуш модель передачи данных сделать, как вы конкретную бизнес цель замапили на фичу системы и почему сделали фичу, а не просто какое-то изменение процесса например, покажите описание какое фиче сделали (сиквенсы, датафлоу и т.д.), как тестеры ваши требования протестировали, кто ПРы принимал и за архитектурой следил, как оценку делали, какой методикой следили за прогрессом, с какой дискретой, что дало, какие решения были приняты на основе метрик ... обычную работу короче РП то опишите, а не это вот все блаблаба.
ох, махнул я коммент, извините если обидело. но на обижены воду возят. а то нам хватает ванильных разработчиков)
Прям по пунктам буду отвечать
На самом деле, вы именно тот, кого я и искал, кто поможет мне отточить подачу постов так, чтобы они заходили большему количеству людей :)
-------------------------------------------------------------------------------------------------------------------------
Где вы увидели утверждение в моих словах? Там стоит слово “если”, которое как раз обуславливает моё предположение, иначе мне совсем неясно зачем заниматься критикой без оснований.
-------------------------------------------------------------------------------------------------------------------------
Дальше, я не задавал вопрос, почему жёстко, я задал вопрос, почему вообще критика с вашей стороны. Критики бывают разные, бывают те, кто как раз “блаблабла”, бывают те, кто несмотря на жесткую подачу, дают конструктив. Надеюсь вы из второго числа.
-------------------------------------------------------------------------------------------------------------------------
После этого, вы говорите про “потому что вы в первом же предложении в целом, то обидели разработчиков”. Первое предложение это “Меня зовут Андрей Глушко. Я менеджер ИТ проектов, занимаюсь менторством, прошёл путь от разработчика до руководителя, в своих подходах опираюсь в первую очередь на людей, а потом уже на практики.”. Где в этом предложении я обидел кого-то? Я сказал за себя, что я прошёл этот путь, и, что я когда работаю с командой, то опираюсь на запросы людей внутри команды. Где я поставил себя выше?
Хорошо, возможно вы имели в виду первое предложение “На своём опыте я понял, что необходимо найти баланс между вовлечением сотрудника в цели компании и его собственными целями.”. Смысл этого предложения заключается в том, что разным сотрудникам, важно не только давать четкие инструкции, а всё-таки давать пространство для анализа и манёвра, потому что это помогает их продуктивности, им не кажется их работа рутинно и тд. Опять же я не вижу, где я здесь вас задел.
-------------------------------------------------------------------------------------------------------------------------
Далее по тексту у вас идёт, как вы говорите “блаблабла”, потому что вновь нет аргумента(аргументов). Вы начали абзац с одного, говоря что мои статьи портят представление о хороших РП - {Ну а во вторых такие статьи портят и без того ОЧЕНЬ скудным мир толковых руководителей}. Внутри того же предложения переключились на то, что мои стать дают плохое направление для новичков - {на старте их отправляют туда, куда лучше не ходить и в целом рисуют им корявую парадигму}. Потом решили упомянуть, что по какой-то причине неделя такая на хабре. А закончили совсем другим - {тут иногда и покритиковать могут}. В итоге я не понял ни одной темы, что вы упомянули.
-------------------------------------------------------------------------------------------------------------------------
Теперь к этому {имхо, вы видели статьи про докер стратегические?). Банальный пример(утрированный) стратегической задачи по докеру: “Нам необходимо уменьшить время от фидбека клиента до релиза изменений запрашиваемых в фидбеке, докер нам может позволить быстрее пересоздавать environment, если какие-либо изменения в коде происходят. Товарищ Вася, пожалуйста контейнеризируй наш сервис”.
Вот пример статьи, который был в первой строчке запроса в гугл https://bobcares.com/blog/rapid-web-application-deployment-how-to-use-docker-to-reduce-time-to-market/ . Там описывают, как для клиентов важно, чтобы они быстрее получали изменения.
-------------------------------------------------------------------------------------------------------------------------
Чтобы я всё это написал и расписал мне требуется время. К сожалению я не могу внутри одной статьи описать проблему со всех сторон, учитывая все детали, расписывая каждый возможный кейс, древо моих мыслей и так далее.
-------------------------------------------------------------------------------------------------------------------------
Я не обижаюсь. Я люблю критику, критика это хорошо. Но я люблю конструктивную критику, а не основанную на аргументе, что я не расписал внутри статьи множество вещей, о которых мог бы написать.
-------------------------------------------------------------------------------------------------------------------------
Как итог. Вы сами понимаете, что именно вы хотите от меня? Если да, то, пожалуйста, напишите мне конкретно, что именно и где именно не так внутри моей статьи
Только это оторвано от реальности. Не, конечно, вы получите аптайм-даунтайм метрики, и успешно освоите деньги инвесторов, но это не то, что вообще требуется клиенту, и не то, что покажет ему, что ваше приложение надежное, потому что никто в это, во первых, не верит, во вторых, не собирается верить. Клиенту важно не то, какие вы себе метрики нарисовали, а что будет, если вы провалите свои обещания.
Ну из разряда: вот вы платите нам абонку 30 баксов в месяц, и по договору, за время даунтайма мы вернем вам деньги. То-есть если месяц будет лежать приложение, то вы вернете 30 долларов. Нормальный клиент скажет "досвидание" если у него будет альтернатива. Но в то же время если вы скажете, что "вот у нас метрики, и даунтайм у нас 1% от общего времени, поэтому если в течении месяца даунтайм будет больше 1%, но меньше 5%, то мы вернем вам всю сумму за месяц, а если больше 5%, то вы получите год бесплатно.
Тогда можно вести диалог. Ну если это приложение корпоративного сегмента, например, где аптайм критически важен, а не какая то считался взмахов телефоном.
А ваши метрики, это просто сферические попугаи в вакууме, которые никому не сдались, потому что всегда можно сказать что "никогда такого не было, это первый раз, что приложение лежит две недели, ну в смысле опять первый раз, а так у нас все ровно по аптайму".
Отсюда никакой из вариантов постановки задачи, описанных в посте, не позволит от сотрудника получить тот вариант предложения для клиента, что я написал выше. Ну со вторым и последующими вариантами все понятно, там просто нужны руки, которые задачу реализуют, но первый вариант так же не дает нужного результата. Отсюда нужно еще научиться ставить задачи так, что бы изначально в них был смысл и практическое применение помимо освоения бюджета инверторов. И вот с этим у менеджеров огромные проблемы. Так как они сами не понимают, что и зачем они делают.
Вы правы, что некоторые фирмы этим злоупотребляют и включают эти метрики в УТП, когда продают свой сервис клиентами или стейкхоледрам, хотя на деле это просто цифры. Однако, у меня есть оптимистические ожидания того, что такой подход в некоторых фирмах будет постепенно уходить в прошлое.
Если говорить про ответственность, когда эти метрики не удовлетворяются, то как раз плюшки по гарантии и могут быть причиной для клиента выбрать вас. Вспомните обычные ритейл магазины, раньше там не было ни обмена, ни возврата, могли ещё и не оригинал подсунуть. Сейчас уже почти стандарт, что в случае брака или причины "не понравилось", покупатель сможет вернуть товар и не понесет финансовых потерь.
Почему я делаю такое сравнение? Потому что ИТ услуги по сути тоже ритейл(компания закупает рабочую силу дешевле, а продаёт результаты рабочей силы дороже), но намного более сложного товара. И этот товар требует, мне кажется, больше времени, чтобы вокруг него организовались стандарты и регуляции в случае обмана или недобросовестного исполнения со стороны "продавца".
В целом все правильно, на мой взгляд. Особенно порадовало то, что вы пытаетесь найти баланс между целями сотрудника и целями компании. Поверьте, сотрудники это ценят. Однако, ничего не сказано про сопровождение сотрудника в процессе выполнения работы. В моей практике никогда не бывало такого, чтобы задача уровня сложности выше очень легкой выполнялась без дополнительных вопросов и согласований. И вот здесь тоже возможны варианты. Например:
Поставить задачу и "уйти в закат" до дедлайна
Поставить задачу и быть на связи
Поставить задачу и требовать ежедневной отчетности о ходе выполнения.
Каждый способ имеет свои плюсы и минусы (даже первый). Было бы здорово почитать и про это.
Мем с ошибками специально добавлен? Это ж явно не эрратив...
TL:DR; Если сотрудник давно работает в конторе и шарит в процессах и технологиях - можно сказать ему "Васян, давай запилим метрики х и у, чтоб менеджер мог на них глядеть". Если сотрудник не шарит в технологиях - "Васян, возьми либу 1, либу 2, почитай про метрики тут, скопируй код отсюда, перемешай, взболтай и сделай, чтобы было красиво". Если Васян совсем новичок в конторе - расписывает ему алгоритм по пунктам.
Основная (единственная?) проблема с таким подходом в ИТ - то, что средний срок работы Васяна в компании 2-3 года. За это время сложно обрасти глубоким пониманием, процессов и окружающих людей.
Поэтому приходится дробить задачи на меньшие куски и отдавать их разным Васянам. Кусок про коммуникацию - тому, кто бухал со всеми на корпоративах. Кусок про выбор решения - тому, кто посмотрел все доки на все либы используемые в конторе. Непосредственную реализацию - тому, кто просто фигачит код и не заморачивается.
По сути - это конвейер, где каждый делает свой кусочек. Но снежинки приходят в ужас о осознания этого факта
в моей практике важнее обозначить критерии приемки задачи, чем цели и мотивации, если не сказать как будешь проверять, ничего и не будет сделано
Если ставить программисту бизнес задачи - ничего хорошего не получиться. Ни для бизнеса, ни для программиста.
Задача нахождения баланса между интересами сотрудника и компании гораздо сложнее и интереснее, чем может показаться на первый взгляд. А происходит это потому, что интересы сотрудника и компании не просто "Не совсем пересекаются", а, скорее всего (не факт, но скорее всего), прямо противоречат друг другу. В чем вообще интересы сотрудника как разработчика? Быть в тренде последних технологий, осваивать постоянно что-то новое и т.д. Однако может ли компания такое предложить? Если это не R&D отдел какой-нибудь крупной корпорации, скорее всего, нет. Смотрите, в стандартном IT-отделе, куда Вы приходите устраиваться, есть проект, которому хотя бы года два. Если менеджмент в отделе толковый, то очевидно, что этот проект два года назад не начинался на cutting-edge фреймворке, у которого на тот момент коммюнити состоит из полутора программистов. Т.е. этот проект начинался на какой-нибудь апробированной технологии, которая уже года два-три хотя бы известна и используется. Получается, что вам в лучше случае удастся поработать на технологиях пятилетней давности. И, естественно, при найме очередного программиста никто не будет резко менять стек проекта, чтоб ему было интересно. Естественно, при заведении нового проекта начинает давить бремя знания - ведь стек старого уже освоен, а с новым стеком еще надо набивать шишки. Поэтому 5 лет устаревания - это еще мягко и весьма неплохо, запросто может оказаться, что программисту надо работать на движке 10-15 летней давности. Это в интересах бизнеса, но не разработчика. И соблюсти здесь баланс руководителю проекта сложно - это одна из самых непростых задач, с которыми он столкнется.
Хорошее замечание. Мой пост действительно не рассказывает про эту часть взаимодействия с сотрудником. У меня есть в планах написать статью про тему, как удерживать сотрудника или лучше сказать, как заинтересовать сотрудника задачами фирмы.
Если вкратце, то в своём подходе я пытаюсь достигнуть хорошей рабочей атмосферы через две вещи. Первое, при найме я дополнительно разговариваю с кандидатом о рабочих принципах, давая ему ситуации, после чего спрашиваю как бы он действовал в них. Так, я по крайней мере набираю людей, которые близки мне по "вайбу". Через это мы сможем легче договариваться. А второе - это уже через открытость к дискуссиям, мы стараемся прийти к компромиссам между его желаниями и тем, что я могу дать внутри проекта, во время нашей совместной работы.
Всё равно ведь в течение проекта потребуется проанализировать разные методы выполнения задачи, проанализировать пути разработки(грубо говоря, нужны ли нам конкретно сейчас микросервисы или нет), также будет возможность сделать презентацию для демо и провести презентацию во время демо, и так далее. Так и появится некая "не рутинность" для сотрудника
технологии это еще малая часть проблемы. Гораздо сложнее - когда разработчику нужно для уточнения требований искать нужных стейкхолдеров, вылавливать неделями, потом разговаривать с ними, а их еще и не один и не два, а требования протеворечивые, лексикон непонятный. И всё настолько выводит из себя простого програмиста который любит писать код, что он воскликакает в сердцах. "Боже, а что если придумать какого-то человека который бы вместо меня ходил бы по всем этим людям, и пусть они капают ему на мозги своими противоречиями и хотелками, а он бы из всего этого треша выдввал мне нормальное ТЕХНИЧЕСКОЕ задание." И Господь услышал молитвы и создал бизнес-аналитика, и посмотрел на труды свои и воскликнул "Да будет так!"
Как я ставлю задачу для сотрудника