аналитик реально плохо составил тз, оба разраба вместо того чтобы остановится когда непонятно в каком формате передавать нафигачили код как вздумалось и решили это все ... введением коммуникации)))
боюсь у вас все трое оказались джунами и ваше "решение" прокачает остальных джунов до такого же уровня;)
ну да, и в первой цепочке забыли про существование тестирования требований.
а кто сказал что мне стало лучше\легче? это называется - Демагогические приёмы. я тоже могу так сделать: "вы не рады, вы пытаетесь выпутаться из того что вас .... блаблабла". видите, я сказал утверждение, сам объявил его истиной и на нем построил дальше предложение. так делать плохо ;)
как я сделал вывод? ну у вас в профиле написано что вы ментор РПшников в ИТ, канал вон свой ведете. пришли со статьей не реальных кейсов, а скорее со "стратегией". А значит хотите задать вектор для юных умов, т.е. джунов.
почему жестко ... потому что вы в первом же предложении в целом, то обидели разработчиков (ни некрасиво это писать от <должность> до <должность> ... вы поставили сразу себя на ранг выше, хотя это разные профессии вообще-то). Ну а во вторых такие статьи портят и без того ОЧЕНЬ скудным мир толковых руководителей, тем что на старте их отправляют туда, куда лучше не ходить и в целом рисуют им корявую парадигму. ну и потому что видимо неделя такая на хабре "стратегов" писать статьи "флаги", прибежали, помахали, думали плюсами закидают? нет, тут иногда и покритиковать могут. вы как говорил один мой друг просто "не в профессии". но увы таких основная масса в мире РП (( вот такая печалька))
имхо, вы видели статьи про докер стратегические?) ну так уместите стратегию свою в пару абзацев и просто поделитесь опытом в статье на конкретном примере что и как делали. как вы выбрали архитектуру когда разраб джун был, откуда у вас был опыт пул или пуш модель передачи данных сделать, как вы конкретную бизнес цель замапили на фичу системы и почему сделали фичу, а не просто какое-то изменение процесса например, покажите описание какое фиче сделали (сиквенсы, датафлоу и т.д.), как тестеры ваши требования протестировали, кто ПРы принимал и за архитектурой следил, как оценку делали, какой методикой следили за прогрессом, с какой дискретой, что дало, какие решения были приняты на основе метрик ... обычную работу короче РП то опишите, а не это вот все блаблаба.
ох, махнул я коммент, извините если обидело. но на обижены воду возят. а то нам хватает ванильных разработчиков)
от разработчика до руководителя! я был никем и стал важным боссом))))
вы и не менеджер и не аналитик и не архитектор, а так, обычный "манагер".
требованиями и в том числе бизнес, пусть занимаются аналитики, архитекторы пусть занимают на чем и как писать код. а вы поймите что руководитель проектов это другое направление деятельности в отличии от разработки и займитесь своими задачами, хотя бы узнайте зачем вообще РП нужен))
сидишь потом на митингах с такими СТО и понимаешь, что самому придется решать что делать, а СТО только флагом помахал и никаких решений не принял. стратеги блин, без практики.
ну для примера мой собственный опыт откликов в 25-27 лет такой же как сейчас. я откликался, ждал реакции, приходил пунктуально, в ответ ждал такой же пунктуальности. мне интересная конкретная работа, работодателю интересен конкретно я. если это не так, зачем тратить время обоих.
просто это не про кейс "к концу февраля закрыть кем то из 150 откликов" с одной стороны и "к концу февраля устроится куда то из 150 откликов" с другой стороны.
разные короче миры, иногда они случайно пересекаются, они отталкиваются. но не стоит делать глобальных выводов из этого количества информации.
статья же не конкретно о вашей команде, с ней все понятно, потому что "формула найма" у вас одна и та же. это не есть опыт вообще то. вы просто довели до совершенства навык конкретно вашего найма. но экстраполируете это на другие возрастные группы, где судя по написанному опыта нет (нет разных опытов работы, нет опыта работы с разными возрастами (костяк до 25))
вам не с чем сравнить и вы не понимаете модели поведения эти как вы их называете "неициативных" людей. поэтому люди юзают HR, ну те которые понимаю хотя бы то, что они вот это (найм) не понимают.
но еще раз, у вас ошибка выжившего, понятно что вы будете сопротивляться думать что вы неправы. так работают когнитивные искажения в нашем мозге, увы для нас (людей). хотя может иначе мы были бы скучным видом))
хм, в статье написано что такую роль нанимают первый раз. а я много "инициативных" ПМов повидал))
ну и, если так нанимали всегда и никогда не брали тех кто "не навязывается", то получается и сравнить не с чем будет, логично же? тогда вам все покажется ок и что наняли кого надо и метод работает. ошибка выжившего же обычная.
ну получит человек, что заслужил при таком подходе к найму, просто "инициативу" от которой устанет и заказчик и устал он сам (а потому и нанял, ведь этот чел ему постоянно писал/звонил и скриншоты присыла, вот он его и нанял, чтобы избавится от этой боли. только не понял, что нанял эту боль себе на работу за свои деньги))))
то есть вы гордитесь и считаете правильным, что вы без аналитики и команды наплодили легаси сразу на старте, которое делало не то что надо и выглядело убожищем, выкатили на прод забив даже на препрод, допинали прод костылями хотфиксов, чтобы ну хоть с костылями, но бизнес-процесс работал, назвали это успехом и… пошли делать следующий «пилот».
я же сильно ничего не забыл?))
ммм… да, есть о чем написать на хабре.
но правильнее было сделать таки аналитику месяца за 3, за это время застафить команду и начать делать контур тестирования, а потом за полгода запилить нормальное решение.
но тут увы нет, как правильно сказали, «слабоумия и отваги»))
все всегда опускают кому нужен потом этот "опыт", который так лихо получается в аутсорсе?
правильно, в продуктовой команде))
потому что никто не хочет вечно менять проекты/команды и получать этот "опыт"
аутсорс это только минус, но хорош как точка входа, поэтому обе стороны понимают рассклады и одни довольны контролируемой текучкой, а вторые "опытом"
ищу статью про инжиниринг менеджера, думаю - о, годный вариант!
а внизу вижу свое упоминание. оказывается есть люди, которые нормально критику воспринимают)
я правильно понял суть, что весь код в мире пишут джуны?)
о, а у вас интересный профиль)
мало интереса к статье, чтобы тратить время и рисовать)
страница конфа -> скрипт -> компонент жира.
все, это вся диаграмма)
ну анкета и анкета, эти вопросы задаст любой кто понимает разработку ПО.
а если не понимает, то даже если и задаст, то не поймет смысла и что делать с ответами.
в чем смысл то писать а без б?)
аналитик реально плохо составил тз, оба разраба вместо того чтобы остановится когда непонятно в каком формате передавать нафигачили код как вздумалось и решили это все ... введением коммуникации)))
боюсь у вас все трое оказались джунами и ваше "решение" прокачает остальных джунов до такого же уровня;)
ну да, и в первой цепочке забыли про существование тестирования требований.
а кто сказал что мне стало лучше\легче? это называется - Демагогические приёмы.
я тоже могу так сделать: "вы не рады, вы пытаетесь выпутаться из того что вас .... блаблабла".
видите, я сказал утверждение, сам объявил его истиной и на нем построил дальше предложение. так делать плохо ;)
как я сделал вывод? ну у вас в профиле написано что вы ментор РПшников в ИТ, канал вон свой ведете. пришли со статьей не реальных кейсов, а скорее со "стратегией". А значит хотите задать вектор для юных умов, т.е. джунов.
почему жестко ... потому что вы в первом же предложении в целом, то обидели разработчиков (ни некрасиво это писать от <должность> до <должность> ... вы поставили сразу себя на ранг выше, хотя это разные профессии вообще-то). Ну а во вторых такие статьи портят и без того ОЧЕНЬ скудным мир толковых руководителей, тем что на старте их отправляют туда, куда лучше не ходить и в целом рисуют им корявую парадигму.
ну и потому что видимо неделя такая на хабре "стратегов" писать статьи "флаги", прибежали, помахали, думали плюсами закидают? нет, тут иногда и покритиковать могут. вы как говорил один мой друг просто "не в профессии". но увы таких основная масса в мире РП (( вот такая печалька))
имхо, вы видели статьи про докер стратегические?)
ну так уместите стратегию свою в пару абзацев и просто поделитесь опытом в статье на конкретном примере что и как делали. как вы выбрали архитектуру когда разраб джун был, откуда у вас был опыт пул или пуш модель передачи данных сделать, как вы конкретную бизнес цель замапили на фичу системы и почему сделали фичу, а не просто какое-то изменение процесса например, покажите описание какое фиче сделали (сиквенсы, датафлоу и т.д.), как тестеры ваши требования протестировали, кто ПРы принимал и за архитектурой следил, как оценку делали, какой методикой следили за прогрессом, с какой дискретой, что дало, какие решения были приняты на основе метрик ... обычную работу короче РП то опишите, а не это вот все блаблаба.
ох, махнул я коммент, извините если обидело. но на обижены воду возят. а то нам хватает ванильных разработчиков)
от разработчика до руководителя! я был никем и стал важным боссом))))
вы и не менеджер и не аналитик и не архитектор, а так, обычный "манагер".
требованиями и в том числе бизнес, пусть занимаются аналитики, архитекторы пусть занимают на чем и как писать код. а вы поймите что руководитель проектов это другое направление деятельности в отличии от разработки и займитесь своими задачами, хотя бы узнайте зачем вообще РП нужен))
сидишь потом на митингах с такими СТО и понимаешь, что самому придется решать что делать, а СТО только флагом помахал и никаких решений не принял. стратеги блин, без практики.
блаблабла и ничего конкретного. надо быть хорошим и не быть плохим.
ничего, в следующем семестре узнаете, что бывает 3 вид памяти))
ну для примера мой собственный опыт откликов в 25-27 лет такой же как сейчас. я откликался, ждал реакции, приходил пунктуально, в ответ ждал такой же пунктуальности. мне интересная конкретная работа, работодателю интересен конкретно я. если это не так, зачем тратить время обоих.
просто это не про кейс "к концу февраля закрыть кем то из 150 откликов" с одной стороны и "к концу февраля устроится куда то из 150 откликов" с другой стороны.
разные короче миры, иногда они случайно пересекаются, они отталкиваются. но не стоит делать глобальных выводов из этого количества информации.
ек макарек))
статья же не конкретно о вашей команде, с ней все понятно, потому что "формула найма" у вас одна и та же. это не есть опыт вообще то. вы просто довели до совершенства навык конкретно вашего найма. но экстраполируете это на другие возрастные группы, где судя по написанному опыта нет (нет разных опытов работы, нет опыта работы с разными возрастами (костяк до 25))
вам не с чем сравнить и вы не понимаете модели поведения эти как вы их называете "неициативных" людей. поэтому люди юзают HR, ну те которые понимаю хотя бы то, что они вот это (найм) не понимают.
но еще раз, у вас ошибка выжившего, понятно что вы будете сопротивляться думать что вы неправы. так работают когнитивные искажения в нашем мозге, увы для нас (людей). хотя может иначе мы были бы скучным видом))
хм, в статье написано что такую роль нанимают первый раз. а я много "инициативных" ПМов повидал))
ну и, если так нанимали всегда и никогда не брали тех кто "не навязывается", то получается и сравнить не с чем будет, логично же? тогда вам все покажется ок и что наняли кого надо и метод работает. ошибка выжившего же обычная.
ну получит человек, что заслужил при таком подходе к найму, просто "инициативу" от которой устанет и заказчик и устал он сам (а потому и нанял, ведь этот чел ему постоянно писал/звонил и скриншоты присыла, вот он его и нанял, чтобы избавится от этой боли. только не понял, что нанял эту боль себе на работу за свои деньги))))
ну и программист был не совсем настоящий, а 1С ;)
такая система по классификации попадает в автоматизированную, а не автоматическую.
просто вы не прочитали даже это
https://ru.m.wikipedia.org/wiki/Информационная_система
вот вас и троллят)
я же сильно ничего не забыл?))
ммм… да, есть о чем написать на хабре.
но правильнее было сделать таки аналитику месяца за 3, за это время застафить команду и начать делать контур тестирования, а потом за полгода запилить нормальное решение.
но тут увы нет, как правильно сказали, «слабоумия и отваги»))
а в чем для того кто первым уходит, профит то делать благо для тех кто остается?