Я называю это наркомания - стремление получить удовлетворение как можно быстрее. На это подсаживаешься, это вызывает привыкание, отсутствие быстрых результатов приводит к ломке и даже - выгоранию. В таком состоянии люди готовы буквально на всё, чтобы получить очередную дозу своего удовольствия сию секунду, даже на преступление.
Когда менеджеры требуют оценку немедленно, программисты коммитят код без тестов, чтобы закрыть задачу, а тестировщики красят в зелёный неглядя - вот это оно.
Да мысли в вашей статье классные. Попытаться описать себя в роли руководителя это хороший способ понять о чём это вообще. Даже оставаясь на ролях специалиста, потом начнёшь больше ценить такую работу. Сложно? Трудно? А то.
Ну вот руководитель со знаниями специалиста, или специалист с организаторскими способностями это комбо, на самом деле не так часто встречающееся в природе. Если вы нашли такого человека, то считайте, что выиграли в лотерею. Они не будут тупить, при виде слов фронтенд-бекенд, или ждать аналитиков, чтобы зафиксировать ключевые решения после встречи. Мне кажется слова Джобса об чём-то таком.
Опять же, рассчитывать на выигрыш в лотерее это так себе стратегия. Поэтому я согласен и с @lair - нужно уметь работать с тем, что имеем.
А что конкретно обязательно делает руководитель команды, кроме руководства?
Рассказывает как и что делать
Задача руководителя выбирать людей и указывать им цели - пресловутые who/what/when, - контролируя потом риски и результаты. А how "как" это работа специалистов - для этого их и нанимают.
Если специалисту приходится рассказывать как делать свою работу, то здесь от руководителя требуется во время определить риск. А дальше нужен просто более опытный специалист: учитель, тренер, наставник, - а не руководитель.
Они, разумеется, тоже будут ставить цели и контролировать результаты - в своих образовательных активностях. Но это занятие немного другого рода.
Я согласен. Хотя, тут как всегда нужно учитывать контекст. Можно быть мидлом на конкретном проекте или даже в целой организации, закрывая таски. Но за рамками делать какие-то продукты. Образовательный курс, канал в соцсетях, музыкальную группу, школу танцев, магазин собранный по принципу no-code/low-code,... да хоть морковку в огороде выращивать и на рынке продавать (у меня есть живые примеры). :)
когда сам вырастаешь до достаточного уровня, можно просто сказать "мое время слишком дорого, чтобы я его тратил на организацию встреч".
Сказать кому? Выглядит скорее как навык пушбэчить, нежели делегировать. Это срабатывает когда ответственность лежит на ком-то другом. Ну то есть собрать контакты, подготовить материалы и презу, написать агенду, а потом mfu с экшен айтемами по результатам это не дорого. А жамкнуть пару кнопок в календаре аутлука - тут без проджекта с аналитиком уже ни как?
Мне кажется продукт это то, что решает проблемы бизнеса. Софт здесь всегда лишь только часть - даже если вы продаете коробки. А в репозиториях лежат исходники приложения, или отдельных его компонентов. Написать работающее приложение и сделать прибыльный продукт это довольно разные вещи.
мне как к архитектору пришли и попросили дизайн для вот такой-то функциональности, то моя задача - сделать такой дизайн, а организовывать процесс его внедрения буду не я.
Ну а кто будет организовать процесс сбора требований, проводить встречи со стейк холдерами, пушить экспертов, верифицировать и оценивать решение с командами? Без организаторских навыков, имхо, тут будет тяжело. Может на начальных этапах карьеры за вас этим будут заниматься более опытные ребята. Но сидеть так вечно в джунах это какой-то инфантилизм.
Обработка ошибок внутри программы и формат сообщений об ошибках наружу это две разные проблемы. Прежде, чем изобретать кастомные решения, я бы рекомендовал посмотреть стандартные.
В первом случае реализация сильно зависит от конкретного языка программирования, фреймворка, принятых соглашений и способов интеграции. Способы, принятые в Java встанут по перек горла, если вы пишите на Golang. Кастомные способы обработки ошибок открывают разработчикам большой простор наделать новых на неизвестном им поле.
Во втором лучше ориентироваться на требования ваших систем мониторинга. Если заранее про них ни чего не известно, то можно брать OpenTelemetry как универсальное решение - сейчас худо-бедно его поддерживают практически все. Здесь же терминология (event, log, span, trace) и необходимые атрибуты, и с большой степенью вероятности- готовые SDK под вашу платформу.
Мидл это способность решать технические задачи без постоянного supervision снаружи. Взять на себя ответственность за подсистему или компонент, и генерировать такие задачи уже самому под контролем старших товарищей - это синьерский скилл.
Ну если вы хотите, чтобы ваши архитектурные решения воплощались в жизнь в том виде, в котором вы это задумали, да и вообще воплощались где-нибудь, то без навыков организовывать и управлять людьми здесь никуда. Людям свойственно делать так, как им удобнее - трения и отклонения норовят возникнуть как со стороны разработки, так и бизнеса. А если вы работаете не в одиночку, а у вас там целая команда, то - тем более.
Какая-то теория заговора на ровном месте. Как-то обидно за приложение, которым давно пользуюсь.
Судя по данным в профиле, ваш аккаунт зарегистрирован на этом сайте в 2013 году. При этом за 10 лет под ним опубликовано 3 комментария. Что интересно, все они появились за последние сутки в новостях, посвященных инциденту с 2gis.
Не стоит обижаться. Здорово, что у приложения есть такие переданные поклонники, способные поддержать ребят в трудной ситуации, совершая даже такие, не слишком характерные для себя поступки. ;)
В теории, здесь мог возникнуть вопрос: откуда у вас данные о платежеспособности и интересах пользователей - если вы ничего лишнего не собираете?
Но в политике конфиденциальности https://law.2gis.ru/privacy/ все условия сбора и использования личных данных довольно подробно расписаны. Я не буду это комментировать - кому интересно сами посмотрят и сделают для себя выводы.
Надеюсь, что возникшая проблема поможет вам сделать правильные выводы и в результате изменить приложение так, чтобы оно действительно стало дружественным и безопасным по отношению к пользователям.
В 2023 году в ходе заседаний рабочей группы, проводившихся в Минске на площадке НАН Беларуси, были рассмотрены актуальные вопросы рабочего взаимодействия как на уровне Роскосмоса и НАН Беларуси, так и на уровне ключевых российских и белорусских организаций, участвующих в сложившейся за многие годы сотрудничества эффективной «космической» кооперации. Основное внимание уделялось анализу и предварительному отбору поступающих материалов по формированию
Здесь на минутку ощутил себя в 1984 1983, где СССР даже не думает перестраиваться, а по телевизору идёт программа "Время". :)
Вообще конечно крутая работа. Интересно это целиком авторский текст или репост чьих-то пресс-релизов?
На сегодняшний день в РФ действуют два репозитория: ЗАО «Национальный расчетный депозитарий», признанный системно значимым, и репозиторий ПАО «Санкт-Петербургская биржа».
Я называю это наркомания - стремление получить удовлетворение как можно быстрее. На это подсаживаешься, это вызывает привыкание, отсутствие быстрых результатов приводит к ломке и даже - выгоранию. В таком состоянии люди готовы буквально на всё, чтобы получить очередную дозу своего удовольствия сию секунду, даже на преступление.
Когда менеджеры требуют оценку немедленно, программисты коммитят код без тестов, чтобы закрыть задачу, а тестировщики красят в зелёный неглядя - вот это оно.
Да мысли в вашей статье классные. Попытаться описать себя в роли руководителя это хороший способ понять о чём это вообще. Даже оставаясь на ролях специалиста, потом начнёшь больше ценить такую работу. Сложно? Трудно? А то.
Ну вот руководитель со знаниями специалиста, или специалист с организаторскими способностями это комбо, на самом деле не так часто встречающееся в природе. Если вы нашли такого человека, то считайте, что выиграли в лотерею. Они не будут тупить, при виде слов фронтенд-бекенд, или ждать аналитиков, чтобы зафиксировать ключевые решения после встречи. Мне кажется слова Джобса об чём-то таком.
Опять же, рассчитывать на выигрыш в лотерее это так себе стратегия. Поэтому я согласен и с @lair - нужно уметь работать с тем, что имеем.
Задача руководителя выбирать людей и указывать им цели - пресловутые who/what/when, - контролируя потом риски и результаты. А how "как" это работа специалистов - для этого их и нанимают.
Если специалисту приходится рассказывать как делать свою работу, то здесь от руководителя требуется во время определить риск. А дальше нужен просто более опытный специалист: учитель, тренер, наставник, - а не руководитель.
Они, разумеется, тоже будут ставить цели и контролировать результаты - в своих образовательных активностях. Но это занятие немного другого рода.
Я согласен. Хотя, тут как всегда нужно учитывать контекст. Можно быть мидлом на конкретном проекте или даже в целой организации, закрывая таски. Но за рамками делать какие-то продукты. Образовательный курс, канал в соцсетях, музыкальную группу, школу танцев, магазин собранный по принципу no-code/low-code,... да хоть морковку в огороде выращивать и на рынке продавать (у меня есть живые примеры). :)
Сказать кому? Выглядит скорее как навык пушбэчить, нежели делегировать. Это срабатывает когда ответственность лежит на ком-то другом. Ну то есть собрать контакты, подготовить материалы и презу, написать агенду, а потом mfu с экшен айтемами по результатам это не дорого. А жамкнуть пару кнопок в календаре аутлука - тут без проджекта с аналитиком уже ни как?
Мне кажется продукт это то, что решает проблемы бизнеса. Софт здесь всегда лишь только часть - даже если вы продаете коробки. А в репозиториях лежат исходники приложения, или отдельных его компонентов. Написать работающее приложение и сделать прибыльный продукт это довольно разные вещи.
Ну а кто будет организовать процесс сбора требований, проводить встречи со стейк холдерами, пушить экспертов, верифицировать и оценивать решение с командами? Без организаторских навыков, имхо, тут будет тяжело. Может на начальных этапах карьеры за вас этим будут заниматься более опытные ребята. Но сидеть так вечно в джунах это какой-то инфантилизм.
Обработка ошибок внутри программы и формат сообщений об ошибках наружу это две разные проблемы. Прежде, чем изобретать кастомные решения, я бы рекомендовал посмотреть стандартные.
В первом случае реализация сильно зависит от конкретного языка программирования, фреймворка, принятых соглашений и способов интеграции. Способы, принятые в Java встанут по перек горла, если вы пишите на Golang. Кастомные способы обработки ошибок открывают разработчикам большой простор наделать новых на неизвестном им поле.
Во втором лучше ориентироваться на требования ваших систем мониторинга. Если заранее про них ни чего не известно, то можно брать OpenTelemetry как универсальное решение - сейчас худо-бедно его поддерживают практически все. Здесь же терминология (event, log, span, trace) и необходимые атрибуты, и с большой степенью вероятности- готовые SDK под вашу платформу.
Мидл это способность решать технические задачи без постоянного supervision снаружи. Взять на себя ответственность за подсистему или компонент, и генерировать такие задачи уже самому под контролем старших товарищей - это синьерский скилл.
Ну если вы хотите, чтобы ваши архитектурные решения воплощались в жизнь в том виде, в котором вы это задумали, да и вообще воплощались где-нибудь, то без навыков организовывать и управлять людьми здесь никуда. Людям свойственно делать так, как им удобнее - трения и отклонения норовят возникнуть как со стороны разработки, так и бизнеса. А если вы работаете не в одиночку, а у вас там целая команда, то - тем более.
Архитектор это профессия. Как и в любой другой сфере деятельности дилетантов здесь тоже хватает. Ну и платят тоже по разному.
Судя по данным в профиле, ваш аккаунт зарегистрирован на этом сайте в 2013 году. При этом за 10 лет под ним опубликовано 3 комментария. Что интересно, все они появились за последние сутки в новостях, посвященных инциденту с 2gis.
Не стоит обижаться. Здорово, что у приложения есть такие переданные поклонники, способные поддержать ребят в трудной ситуации, совершая даже такие, не слишком характерные для себя поступки. ;)
А вот на https://content.2gis.ru/ в одном из слайдов пишут:
В теории, здесь мог возникнуть вопрос: откуда у вас данные о платежеспособности и интересах пользователей - если вы ничего лишнего не собираете?
Но в политике конфиденциальности https://law.2gis.ru/privacy/ все условия сбора и использования личных данных довольно подробно расписаны. Я не буду это комментировать - кому интересно сами посмотрят и сделают для себя выводы.
Надеюсь, что возникшая проблема поможет вам сделать правильные выводы и в результате изменить приложение так, чтобы оно действительно стало дружественным и безопасным по отношению к пользователям.
Госпад это теперь планшет для потребления госуслуг. Удивительно, что ещё нет в продаже.
Здесь на минутку ощутил себя в
19841983, где СССР даже не думает перестраиваться, а по телевизору идёт программа "Время". :)Вообще конечно крутая работа. Интересно это целиком авторский текст или репост чьих-то пресс-релизов?
Прокторинг здесь родственные прокуратор, прокуратура, прокурор. Прокталгия это потом у тех, кто лекции прогуливал.
$100