А как насчёт свободного времени? Если так подумать, надо работать 8 часов в день + время на переходы (ну пусть час) + время на обед (ещё полчаса-час). Все равно получается работа занимает абсолютно весь день. И точно больше времени, чем если спокойно работать дома и делать разминку каждые 1.5 часа, например. Вы так постоянно работаете или день-два в неделю? Просто тут может быть и обратный эффект - в какой-то момент покажется, что только и делаешь, что работаешь везде, а личного пространства и нет. Опять же с одной стороны вроде личное в работу добавили - пьем кофе, сидим с друзьями, а с другой стороны - работаем всегда и везде. А это путь к выгоранию.
Про эффективность тоже есть момент - а повышается ли она на самом деле по показателям? С одной стороны вам кажется, что вы суперэффективны потому, что вы прогулялись, попили кофе и вроде как сделали задачу быстро, а с другой стороны ваш начальник - понимает, что если бы вы сидели и эти 1.5 часа работали, то сделали бы две задачи (тут конечно небольшая ирония).
Тут, конечно, все зависит от человека. Для меня, например, важно, чтобы было несколько свободных часов в день, которые я могу посвятить себе и семье и не думать о работе. Ну хотя бы те же 2 часа на зарядку или прогулку. Поэтому я лучше поработаю из дома с небольшими перерывами, но буду иметь достаточно большой промежуток свободного времени. Но я знаю людей, для которых важно ощущение движения жизни, им надо, чтобы картинка менялась, и им действительно скучно в офисе.
Интересно бы глянуть и ваш распорядок дня, может ещё пост напишете из серии один мой день? :-)
Меняя локации я могу продуктивно выполнять свои задачи до девяти часов в день, при этом особо не уставая.
Не оказывается ли, что около 2 часов тратится на перемещение между локациями? Тема-то интересная, но для меня смотрится как попытка вкрапления часов личной жизни в работу - "вот сижу в кофейне", но на самом деле не сижу и отдыхаю, глядя на снежинки за окном, а работаю. Может тем у кого есть такая возможность проще и лучше делать полноценную сиесту как раз часа на 2, и распоряжаться ей как угодно от прогулки и обеда до тренажерки. Более менее рабочим смотрится вариант - полдня в коворкинге или офисе, а полдня, например, дома, но менять несколько мест в день, как и работать во время обеда - это явно не для всех.
Мне стабильно на каждом собеседовании задавали вопрос про то, а планирую ли я в декрет в ближайшие 5 лет. Всегда отвечала - "не планирую, но случаи-то всякие бывают" :-D. А во времена учебы в универе в одной из компаний предпочли моего одногруппника троечника и в лицо сказали "да ты замуж через год выйдешь". Вышла правда через 4, не угадали:-D
Вы правы, конечно. Я только за, если такое получается. Но есть вариант, когда хороший старт в карьере заменится на семью. У мужчин такого обычно не случается. Просто хотелось подчеркнуть, чтобы не забывали, что большинство женщин все же ещё и мамы и хозяйки, и это тоже очень важная роль. Может поэтому они и не лиды, ведь не у всех получается все и везде успевать.
А так да - у всех по-разному, могут быть и младенцы разные, у кого-то спокойные, у кого-то капризные, кто-то няню нанимает, чтобы работать,а кто-то хочет большую часть времени посвящать семье. Поэтому и тут часть женщин уходит из программирования в смежные области, а часть теряет былую мотивацию (перерасставляет приоритеты). Но про мотивацию, конечно, и у мужчин бывают разные случаи - это уже скорее в тему оценки качеств программиста.
Вообще поразительно - тема поста была про токсичность, но интересно как переросло в обсуждение сексизма и доли женщин-программистов. Эх, а может голосование провести посчитать сколько женщин и сколько мужчин в нескольких областях (например аналитика, программирование, тестирование)..
Слушайте, у вас больше феминитивов в тексте, чем у меня женщины. Вот вас довели злые тетки :)). Вообще не беря хороших-нехороших как определение качества.. Женщин-разработчиков к мужчинам-разработчикам смотрится где-то как 1/10, все зависит от отрасли (это конечно мои субъективные представления об известных мне компаниях и распределении студентов после окончания универа). Конечно, в программировании на сях для железок женщин почти нет. Вопрос в том, что дорастет женщина до мидла/сеньора и будет даже хорошим разработчиком, а дальше уйдет в декрет и вопрос - выберется ли она оттуда успешно или нет. Потому, что за 3 года многое изменится, а все, что было раньше станет уже легаси. и в разработке изменений больше,чем в ручном тестировании или аналитике. Ну по крайней мере мне как разработчику так кажется (тут могут прибежать тестировщики и забить меня тапками)
Ну тогда чем вас не устроила автор поста как пример. Возьмём например фирмы Data Art или Еpam, там точно есть женщины разработчики. Но вам покажешь, а вы начнёте спрашивать "А хороший ли разработчик?" Не давая критериев как определить хорошего :-D
Очень понравился ваш комментарий, со многим согласна. А про сексизм и блондинок: долгое время работая преподавателем заметила, что парни-студенты больше уделяют внимания ярко и хорошо одетым и накрашенным барышням при полном параде (при прочих равных в симпатичности), скажем так, потому что глаз цепляется. Так вот очень мало из таких ярких девушек действительно уделяет повышенное внимание учебе (из тех, что мне встретились за больше чем 10 лет преподавания, могу вспомнить не больше 5 девушек успевающих все и при этом выглядеть как для съемки в рекламе каждый раз). А у остальных желающих быть яркими идёт расстановка приоритетов - задачу писать или стрелки рисовать. Поэтому вместо того, чтобы на паре решать задачи, смотрят как рисовать стрелки и потом ищут парня, который бы им написал задачу. Вот я и думаю, а может запомнились ещё с учебы только эти яркие девушки, вот и сексизм и шутки по отношению к остальным.
Но с возрастом мироощущение дожно меняться и приближаться к вашему 1 пункту
Интересно послушать критерии хорошего разработчика.. Есть много крутых спортивных программистов, которые не могут нормально разрабатывать корпоративные приложения. То же самое с некоторыми крутыми хакатонщиками, запала которых хватает максимум на неделю. В одной компании человек будет лидом, а в другой джуном.
А про девочек? Тут женщина пишет о 15 годах опыта, может вы девочек-сеньоров и не видели, потому что они в 25 лет все закончились(уж не знаю как людей старше девочками-мальчиками называть), а до сеньора просто ещё не успели дорасти. А может область у вас какая-нибудь вроде производства черных металлов и нет на заводе женщин программистов. (Токсичный юмор, уж извините).
"лучшие ПМы всё-таки вырастают из разработчиков" - субъективное мнение, возможно подкреплённое узкой личной выборкой
Возможно мне не везло с ПМами не из разработки, а возможно у меня не хватает терпения, чтобы каждый раз объяснять ПМу бизнес-аналитику почему например десктопная команда (WinForms) не может за 2 часа нарисовать круглую переливающуюся кнопку, а веб команда может. Всё-таки чаще всего большую часть времени занимает разработка, проблем и недооценок как по мне чаще тоже в ней сильно больше, чем в том же тестировании. Банально хочется, чтобы человек понимал, что код писать - это не траншею копать, не в любой момент остановиться, переключиться и не потерять при этом скорость, не говоря уже о выползающих проблемах и вопросах "а что так долго?".
лучшие ПМ вырастают из тестировщиков. ПМ из разрабов - слишком сильно лезет в разработку и мешает команде
Как вариант согласна, ПМ из тестировщиков будет лезть с советами к тестировщикам)))) И со сроками проблем будет меньше - будет бояться за сдвиги тестирования)) Но все это юмор. На первых этапах действительно микроменеджмент после ухода в ПМ бывает очень часто, но со временем это должно проходить.
Ради интереса даже посмотрела. Есть штук 10 филе трески разных производителей с калорийностью от 69 до 85. Ну не знаете допустим производителя, ну выберите среднюю калорийность из списка,вы же все равно не знаете сколько в вашем куске калорийность + даже в табличках диетологов она примерная. Вы же не делаете химический анализ филе трески, которое покупаете. Более того затрачиваемую телом калорийность тоже только примерно можно посчитать. Готовые блюда вообще из сырого считаются, поэтому готовый суп из приложения у вас очень примерно сойдется с вашим готовым супом, но вы можете честно добавить в список свой. Для просто худеющих такой приблизительный подсчет незначительная проблема, если не считать сладкую газировку как 0 :))). вопрос захочет ли человек заморачиваться с подсчётом или выберет правило тарелки или заранее составленный рацион. Вы так трудните, что представьте как живётся больным инсулинзависимым диабетом, которым надо достаточно точно знать сколько БЖУ они едят каждый раз, чтобы не ошибаться с дозой инсулина и жить нормально.
Брать в работу на 2 дня, то что ты оценил в 4, потому что твой pm уже закоммитился на послезавтра перед вицепрезилентом... Зачем хз, но теперь он говорит, что мы команда и надо всем постараться
При этом сам ПМ будет в это время чайка менеджером :))) ох уж извините, что "смеюсь" над ПМами, но про "мы команда" в точку.
Так почему вы считаете, что разработчик это шаг назад? Шаг назад - это, возможно, для того, кто работал разработчиком и ушел из сеньора или Лида в менеджмент,а потом решил обратно в разработчики, а для вас - это шаг в другую сторону, но никак не назад. А вообще лучшие ПМы всё-таки вырастают из разработчиков, потому что, как вы и написали ,они знают "цену" оценкам, на своей шкуре прошли адские переработки в срочном порядке и, главное, говорят на одном языке с разработчиками. Так что может для вас это как раз ещё и вложение в будущий рост снова как ПМа.
Правильно говорите, но для меня как для техлида всегда была проблема выбить у начальства время на менторинг джуна. Я не против делиться знаниями и выращивать достойных коллег, с которыми мне же и придется потом работать, но в последний раз это привело к минимум 10-часовому рабочему дню у меня на протяжении 3 месяцев, где 2 часа в день точно уходило на джуна, и винить его нельзя, он хорошо работал для своего уровня, просто сложная итерация, новый человек в предметной области и стеке, соответственно куча вопросов и обсуждений. И приходится спорить и выбивать время, не всегда успешно (а ПМу ты нравишься все меньше потому, что посигаешь на изменение его расписания). А размазывать менторинг между несколькими людьми ну крайне тяжело, потому что это сломанный телефон - кто, кому, что сказал.
Ну так вы варите например гречку мистраль и пишите в поиск гречку мистраль, особой проблемы в этом нет. Зато база такая большая, что используется и в других приложениях с красивым интерфейсом и кучей функций, например у samsung было родное samsung health и можно было подключить базу fs. А ошибки в КБЖУ случаются и естественны, потому что продукты вводят люди и ошибаются (это везде может случиться). Но вы думаете состав продукта из магазина, указанный на упаковке, содержит четкое КБЖУ? Это среднее + мухлюют и тоже ошибаются. Как-то видела обсуждение булки из кулинарии супермаркета с нулевыми углеводами, один белок))). Если вы конечно одно и тоже постоянно едите, то приложение и не нужно. Рассчитали свои блюда и пользуйтесь. Но надолго ли...
Очень многие пользуются fat secret, там очень большая база продуктов. В принципе даже с бесплатными функциями можно заранее рассчитать питание на день. Вы его пробовали? Он может оказаться удобнее чем ваша табличка. Если честно, когда мне было 20, я начинала вообще с блокнотика и распечатанной таблички с КБЖУ, могу сказать, что именно этот ручной подсчет многому меня научил, поэтому думаю, что ваша Пандочка вас тоже научила, но все же готовое приложение в телефоне с большой базой может быть гораздо удобнее.
В agile/scrum я вижу очень значимый плюс - все, что не успели переносится в другую итерацию, и все счастливы. но увы у нас это не работает. А про нежелание брать сложные задачи - это особенность большинства людей, поэтому задачи надо раздавать в соответствии с должностями и умениями, мониторить прогресс и помогать, если надо. Как-то работала в команде с программистом, который, несмотря на приоритеты, сначала всегда фиксил лёгкие баги, а потом при приближении к релизу оставалась куча хороших багов, заассайненных на него, и их приходилось разгребать всем вместе в срочном порядке и с переработками. И ПМ эту ситуацию знал, даже устанавливал специально для него приоритеты, но программист особо не менял свое поведение, и где можно действовал по своей старой схеме. Поэтому мое мнение, какую бы хорошую методологию не придумали, какие бы классные не были ПМ, скрам-мастер, тим- и техлиды, все равно найдутся либо недовольные, либо пытающиеся как-то все это обойти люди. А про метрики эффективности - к сожалению большинство ПМов нормально их не анализируют, тут только в каждом случае разбираться, что не так. "Неэффективность" кстати и на мелких задачах может случаться часто, потому что недооценили или пропустили что-то, а человек вместо того, чтобы идти разбираться и заводить новую задачу, подумал "да ладно сейчас я быстро" и не получилось.
Ну как не видела - только вылезла после 15 лет в аутсорсе, мне правда платили за каждый час переработки, и я точно знала, на что подписываюсь, когда ситуация меня перестала устраивать - я ушла.
Но вы путаете "вовлечённость" с "увлеченностью", вовлечённость - это про качество, про сообщение о проблемах, которые видишь и про обратную связь, а "увлеченность" как раз про переработки во благо продукта и часто в ущерб себе. Причем если честно-то, переработки чаще всего и не связаны с желанием сделать лучше, а потому что оценки неверные или команда не успела по какой-то другой причине (вот как в вашем примере про смену концепций. Тут надо ПМу идти и давить руководство, но он не хочет и давит команду). А вот время свое надо учиться отстаивать обязательно. В конце концов ПМ не видит, что работник устал и болеет уже, его задача - уложиться в расписание. А свое здоровье и жизнь может контролировать только сам работник. Был такой классный фильм "Одержимость" про барабанщика. Вот в принципе про увлеченность - разобьем пальцы в кровь о клавиатуру и не будем спать.
А можем сделать "кое-как" за N/2. И нюанс в том, что большинство заказчиков и работодателей выберут второе - потому что в два раза в дешевле
Про выбор не лучшего решения: Да, если руководство говорит "давайте делать дёшево и плохо", то тут мы мало что может сделать, но наша цель - ещё раз попытаться донести самые плохие моменты, и задокументировать, чтобы было куда потом носом тыкать, когда спросят почему так сделали. Если есть долгосрочная перспектива с переделкой - то завести enhancement и положить его в нужный "ящик" :))). Все это и для того, чтобы самим помнить и чтобы заказчику показывать, если возникнут претензии. Но это о бизнесе и процессах... И никак не связано с вовлечённостью, с вовлечённостью связано - будете ли вы доносить до руководства плохие и хорошие стороны решений, варианты, возможные проблемы и т.д., будете ли вы вообще думать о решении, которое вам предложили или скажете "ок, как сказали, так и сделаю".
вы загляните в комментарии к соседнему посту про критику, там чуть ли не каждый второй топит про "кто предложил, тот пусть и делает".
Вот это на самом деле и пугает. Ведь по идее при налаженных процессах в этом нет никакой проблемы - баг или улучшение, приоритет, оценка времени и назначенный человек. А получается, что каждый второй сидящий на Хабре работает в компаниях, где нет модного agile/scram, где все запихивают в одну текущую итерацию, но при этом все на каждом столбе пишут как правильно менеджить проекты :-D
Ну, вовлечённость - по мне это желание сотрудника сделать хороший продукт, отсутствие банальной халатности (что как раз и означает "по совести"), понимание того, куда движется проект, да и вообще понимание предметной области большее чем его конкретная таска. И это не только к программистам, а ко всем людям. Например, пример про программистов и тестировщиков: был у нас десктопный проект и надо было напилить новую фичу. В фиче была форма с текстовыми полями и выпадающими списками. Были и требования от бизнес аналитика, в которых в том числе описана эта куча полей, а вот сортировку указали только для нестандартных полей, которые отличны от сортировки по алфавиту. Так вот в одном из таких полей был достаточно большой список, выгружаемый из БД. Ну и программист его не отсортировал, как выгружается - так и показывается. Пока отлаживался его это не смущало, потому что он смотрел не на сами данные, а загружаются они или нет. Тестировщик тоже это пропустил, хотя тестировал именно эту форму не один раз, как он сказал потом "потому что в ТЗ этого не написано". Нашел тимлид, который решил прощелкать проект перед выдачей заказчику и увидел жутко неудобный неотсортированный выпадающий список. Так вот, конечно, можно сказать, что во всем виноват бизнес-аналитик, который должен каждый чих прописать в требованиях, но вроде как тестировщики у нас называются QA, что означает контроль качества и именно они больше всего общаются с приложением и они-то могут подать голос и сказать "ребята, мне вот тут так неудобно и пользователю тоже будет, давайте хотя бы enhancement создадим". А по факту причина здесь - та же невовлеченность... Тестировщик не думал, что он делает, и как это должно выглядеть в реальной жизни, он следовал только тому, что написано; ему неинтересна работа, хочется денег и домой смотреть сериальчики. Поэтому, для меня вовлечённость - это не желание работодателя заставить всех пахать бесплатно, а желание работника сделать хороший продукт, за который не стыдно, внимательно относиться к своей работе и не бояться высказывать свое мнение об улучшениях. А почему-то многие мыслят, что им скажут - "ты предложил, ты и делай в свободное время". А про работодателей и пахать - вспомните, что вы тоже сторона трудовых отношений, и вы соглашаетесь на предложенные условия.В статье, кстати, по пахать откровенно ничего не нашла, наоборот в первом абзаце говорится о желании сделать хорошо, что никак не равно пахать ..
Не поверите, компания, в которой я проработала долгое время, имеет и хороший офис и бесплатные обеды, и зарплата и ноуты хорошие, полугодовые ревью с обратной связью, бонусы к зарплате за техлидство, ПМство и т.д., но все равно в какой-то момент компания резко росла, надо было много специалистов, планка приема опустилась, и появилась куча молодых людей 24-26 лет, которые, видимо, читали книги из серии "как не работать и получать больше". Они воспринимают плюшки как должное, а не как дополнительный стимул, и не выходят на работу потому что "не в ресурсе". Менеджеры и техлиды тоже из этих людей вырастают и тут начинается интересное - их цель не сделать качественный проект, а сделать его с "зелёным" статусом.
А как насчёт свободного времени? Если так подумать, надо работать 8 часов в день + время на переходы (ну пусть час) + время на обед (ещё полчаса-час). Все равно получается работа занимает абсолютно весь день. И точно больше времени, чем если спокойно работать дома и делать разминку каждые 1.5 часа, например. Вы так постоянно работаете или день-два в неделю? Просто тут может быть и обратный эффект - в какой-то момент покажется, что только и делаешь, что работаешь везде, а личного пространства и нет. Опять же с одной стороны вроде личное в работу добавили - пьем кофе, сидим с друзьями, а с другой стороны - работаем всегда и везде. А это путь к выгоранию.
Про эффективность тоже есть момент - а повышается ли она на самом деле по показателям? С одной стороны вам кажется, что вы суперэффективны потому, что вы прогулялись, попили кофе и вроде как сделали задачу быстро, а с другой стороны ваш начальник - понимает, что если бы вы сидели и эти 1.5 часа работали, то сделали бы две задачи (тут конечно небольшая ирония).
Тут, конечно, все зависит от человека. Для меня, например, важно, чтобы было несколько свободных часов в день, которые я могу посвятить себе и семье и не думать о работе. Ну хотя бы те же 2 часа на зарядку или прогулку. Поэтому я лучше поработаю из дома с небольшими перерывами, но буду иметь достаточно большой промежуток свободного времени. Но я знаю людей, для которых важно ощущение движения жизни, им надо, чтобы картинка менялась, и им действительно скучно в офисе.
Интересно бы глянуть и ваш распорядок дня, может ещё пост напишете из серии один мой день? :-)
Не оказывается ли, что около 2 часов тратится на перемещение между локациями? Тема-то интересная, но для меня смотрится как попытка вкрапления часов личной жизни в работу - "вот сижу в кофейне", но на самом деле не сижу и отдыхаю, глядя на снежинки за окном, а работаю. Может тем у кого есть такая возможность проще и лучше делать полноценную сиесту как раз часа на 2, и распоряжаться ей как угодно от прогулки и обеда до тренажерки. Более менее рабочим смотрится вариант - полдня в коворкинге или офисе, а полдня, например, дома, но менять несколько мест в день, как и работать во время обеда - это явно не для всех.
Мне стабильно на каждом собеседовании задавали вопрос про то, а планирую ли я в декрет в ближайшие 5 лет. Всегда отвечала - "не планирую, но случаи-то всякие бывают" :-D. А во времена учебы в универе в одной из компаний предпочли моего одногруппника троечника и в лицо сказали "да ты замуж через год выйдешь". Вышла правда через 4, не угадали:-D
Вы правы, конечно. Я только за, если такое получается. Но есть вариант, когда хороший старт в карьере заменится на семью. У мужчин такого обычно не случается. Просто хотелось подчеркнуть, чтобы не забывали, что большинство женщин все же ещё и мамы и хозяйки, и это тоже очень важная роль. Может поэтому они и не лиды, ведь не у всех получается все и везде успевать.
А так да - у всех по-разному, могут быть и младенцы разные, у кого-то спокойные, у кого-то капризные, кто-то няню нанимает, чтобы работать,а кто-то хочет большую часть времени посвящать семье. Поэтому и тут часть женщин уходит из программирования в смежные области, а часть теряет былую мотивацию (перерасставляет приоритеты). Но про мотивацию, конечно, и у мужчин бывают разные случаи - это уже скорее в тему оценки качеств программиста.
Вообще поразительно - тема поста была про токсичность, но интересно как переросло в обсуждение сексизма и доли женщин-программистов. Эх, а может голосование провести посчитать сколько женщин и сколько мужчин в нескольких областях (например аналитика, программирование, тестирование)..
Слушайте, у вас больше феминитивов в тексте, чем у меня женщины. Вот вас довели злые тетки :)). Вообще не беря хороших-нехороших как определение качества.. Женщин-разработчиков к мужчинам-разработчикам смотрится где-то как 1/10, все зависит от отрасли (это конечно мои субъективные представления об известных мне компаниях и распределении студентов после окончания универа). Конечно, в программировании на сях для железок женщин почти нет. Вопрос в том, что дорастет женщина до мидла/сеньора и будет даже хорошим разработчиком, а дальше уйдет в декрет и вопрос - выберется ли она оттуда успешно или нет. Потому, что за 3 года многое изменится, а все, что было раньше станет уже легаси. и в разработке изменений больше,чем в ручном тестировании или аналитике. Ну по крайней мере мне как разработчику так кажется (тут могут прибежать тестировщики и забить меня тапками)
Ну тогда чем вас не устроила автор поста как пример. Возьмём например фирмы Data Art или Еpam, там точно есть женщины разработчики. Но вам покажешь, а вы начнёте спрашивать "А хороший ли разработчик?" Не давая критериев как определить хорошего :-D
Очень понравился ваш комментарий, со многим согласна. А про сексизм и блондинок: долгое время работая преподавателем заметила, что парни-студенты больше уделяют внимания ярко и хорошо одетым и накрашенным барышням при полном параде (при прочих равных в симпатичности), скажем так, потому что глаз цепляется. Так вот очень мало из таких ярких девушек действительно уделяет повышенное внимание учебе (из тех, что мне встретились за больше чем 10 лет преподавания, могу вспомнить не больше 5 девушек успевающих все и при этом выглядеть как для съемки в рекламе каждый раз). А у остальных желающих быть яркими идёт расстановка приоритетов - задачу писать или стрелки рисовать. Поэтому вместо того, чтобы на паре решать задачи, смотрят как рисовать стрелки и потом ищут парня, который бы им написал задачу. Вот я и думаю, а может запомнились ещё с учебы только эти яркие девушки, вот и сексизм и шутки по отношению к остальным.
Но с возрастом мироощущение дожно меняться и приближаться к вашему 1 пункту
Интересно послушать критерии хорошего разработчика.. Есть много крутых спортивных программистов, которые не могут нормально разрабатывать корпоративные приложения. То же самое с некоторыми крутыми хакатонщиками, запала которых хватает максимум на неделю. В одной компании человек будет лидом, а в другой джуном.
А про девочек? Тут женщина пишет о 15 годах опыта, может вы девочек-сеньоров и не видели, потому что они в 25 лет все закончились(уж не знаю как людей старше девочками-мальчиками называть), а до сеньора просто ещё не успели дорасти. А может область у вас какая-нибудь вроде производства черных металлов и нет на заводе женщин программистов. (Токсичный юмор, уж извините).
Возможно мне не везло с ПМами не из разработки, а возможно у меня не хватает терпения, чтобы каждый раз объяснять ПМу бизнес-аналитику почему например десктопная команда (WinForms) не может за 2 часа нарисовать круглую переливающуюся кнопку, а веб команда может. Всё-таки чаще всего большую часть времени занимает разработка, проблем и недооценок как по мне чаще тоже в ней сильно больше, чем в том же тестировании. Банально хочется, чтобы человек понимал, что код писать - это не траншею копать, не в любой момент остановиться, переключиться и не потерять при этом скорость, не говоря уже о выползающих проблемах и вопросах "а что так долго?".
Как вариант согласна, ПМ из тестировщиков будет лезть с советами к тестировщикам)))) И со сроками проблем будет меньше - будет бояться за сдвиги тестирования)) Но все это юмор. На первых этапах действительно микроменеджмент после ухода в ПМ бывает очень часто, но со временем это должно проходить.
Ради интереса даже посмотрела. Есть штук 10 филе трески разных производителей с калорийностью от 69 до 85. Ну не знаете допустим производителя, ну выберите среднюю калорийность из списка,вы же все равно не знаете сколько в вашем куске калорийность + даже в табличках диетологов она примерная. Вы же не делаете химический анализ филе трески, которое покупаете. Более того затрачиваемую телом калорийность тоже только примерно можно посчитать. Готовые блюда вообще из сырого считаются, поэтому готовый суп из приложения у вас очень примерно сойдется с вашим готовым супом, но вы можете честно добавить в список свой. Для просто худеющих такой приблизительный подсчет незначительная проблема, если не считать сладкую газировку как 0 :))). вопрос захочет ли человек заморачиваться с подсчётом или выберет правило тарелки или заранее составленный рацион. Вы так трудните, что представьте как живётся больным инсулинзависимым диабетом, которым надо достаточно точно знать сколько БЖУ они едят каждый раз, чтобы не ошибаться с дозой инсулина и жить нормально.
При этом сам ПМ будет в это время чайка менеджером :))) ох уж извините, что "смеюсь" над ПМами, но про "мы команда" в точку.
Так почему вы считаете, что разработчик это шаг назад? Шаг назад - это, возможно, для того, кто работал разработчиком и ушел из сеньора или Лида в менеджмент,а потом решил обратно в разработчики, а для вас - это шаг в другую сторону, но никак не назад. А вообще лучшие ПМы всё-таки вырастают из разработчиков, потому что, как вы и написали ,они знают "цену" оценкам, на своей шкуре прошли адские переработки в срочном порядке и, главное, говорят на одном языке с разработчиками. Так что может для вас это как раз ещё и вложение в будущий рост снова как ПМа.
Правильно говорите, но для меня как для техлида всегда была проблема выбить у начальства время на менторинг джуна. Я не против делиться знаниями и выращивать достойных коллег, с которыми мне же и придется потом работать, но в последний раз это привело к минимум 10-часовому рабочему дню у меня на протяжении 3 месяцев, где 2 часа в день точно уходило на джуна, и винить его нельзя, он хорошо работал для своего уровня, просто сложная итерация, новый человек в предметной области и стеке, соответственно куча вопросов и обсуждений. И приходится спорить и выбивать время, не всегда успешно (а ПМу ты нравишься все меньше потому, что посигаешь на изменение его расписания). А размазывать менторинг между несколькими людьми ну крайне тяжело, потому что это сломанный телефон - кто, кому, что сказал.
Ну так вы варите например гречку мистраль и пишите в поиск гречку мистраль, особой проблемы в этом нет. Зато база такая большая, что используется и в других приложениях с красивым интерфейсом и кучей функций, например у samsung было родное samsung health и можно было подключить базу fs. А ошибки в КБЖУ случаются и естественны, потому что продукты вводят люди и ошибаются (это везде может случиться). Но вы думаете состав продукта из магазина, указанный на упаковке, содержит четкое КБЖУ? Это среднее + мухлюют и тоже ошибаются. Как-то видела обсуждение булки из кулинарии супермаркета с нулевыми углеводами, один белок))). Если вы конечно одно и тоже постоянно едите, то приложение и не нужно. Рассчитали свои блюда и пользуйтесь. Но надолго ли...
Очень многие пользуются fat secret, там очень большая база продуктов. В принципе даже с бесплатными функциями можно заранее рассчитать питание на день. Вы его пробовали? Он может оказаться удобнее чем ваша табличка. Если честно, когда мне было 20, я начинала вообще с блокнотика и распечатанной таблички с КБЖУ, могу сказать, что именно этот ручной подсчет многому меня научил, поэтому думаю, что ваша Пандочка вас тоже научила, но все же готовое приложение в телефоне с большой базой может быть гораздо удобнее.
В agile/scrum я вижу очень значимый плюс - все, что не успели переносится в другую итерацию, и все счастливы. но увы у нас это не работает. А про нежелание брать сложные задачи - это особенность большинства людей, поэтому задачи надо раздавать в соответствии с должностями и умениями, мониторить прогресс и помогать, если надо. Как-то работала в команде с программистом, который, несмотря на приоритеты, сначала всегда фиксил лёгкие баги, а потом при приближении к релизу оставалась куча хороших багов, заассайненных на него, и их приходилось разгребать всем вместе в срочном порядке и с переработками. И ПМ эту ситуацию знал, даже устанавливал специально для него приоритеты, но программист особо не менял свое поведение, и где можно действовал по своей старой схеме. Поэтому мое мнение, какую бы хорошую методологию не придумали, какие бы классные не были ПМ, скрам-мастер, тим- и техлиды, все равно найдутся либо недовольные, либо пытающиеся как-то все это обойти люди. А про метрики эффективности - к сожалению большинство ПМов нормально их не анализируют, тут только в каждом случае разбираться, что не так. "Неэффективность" кстати и на мелких задачах может случаться часто, потому что недооценили или пропустили что-то, а человек вместо того, чтобы идти разбираться и заводить новую задачу, подумал "да ладно сейчас я быстро" и не получилось.
Ну как не видела - только вылезла после 15 лет в аутсорсе, мне правда платили за каждый час переработки, и я точно знала, на что подписываюсь, когда ситуация меня перестала устраивать - я ушла.
Но вы путаете "вовлечённость" с "увлеченностью", вовлечённость - это про качество, про сообщение о проблемах, которые видишь и про обратную связь, а "увлеченность" как раз про переработки во благо продукта и часто в ущерб себе. Причем если честно-то, переработки чаще всего и не связаны с желанием сделать лучше, а потому что оценки неверные или команда не успела по какой-то другой причине (вот как в вашем примере про смену концепций. Тут надо ПМу идти и давить руководство, но он не хочет и давит команду). А вот время свое надо учиться отстаивать обязательно. В конце концов ПМ не видит, что работник устал и болеет уже, его задача - уложиться в расписание. А свое здоровье и жизнь может контролировать только сам работник. Был такой классный фильм "Одержимость" про барабанщика. Вот в принципе про увлеченность - разобьем пальцы в кровь о клавиатуру и не будем спать.
Про выбор не лучшего решения: Да, если руководство говорит "давайте делать дёшево и плохо", то тут мы мало что может сделать, но наша цель - ещё раз попытаться донести самые плохие моменты, и задокументировать, чтобы было куда потом носом тыкать, когда спросят почему так сделали. Если есть долгосрочная перспектива с переделкой - то завести enhancement и положить его в нужный "ящик" :))). Все это и для того, чтобы самим помнить и чтобы заказчику показывать, если возникнут претензии. Но это о бизнесе и процессах... И никак не связано с вовлечённостью, с вовлечённостью связано - будете ли вы доносить до руководства плохие и хорошие стороны решений, варианты, возможные проблемы и т.д., будете ли вы вообще думать о решении, которое вам предложили или скажете "ок, как сказали, так и сделаю".
Вот это на самом деле и пугает. Ведь по идее при налаженных процессах в этом нет никакой проблемы - баг или улучшение, приоритет, оценка времени и назначенный человек. А получается, что каждый второй сидящий на Хабре работает в компаниях, где нет модного agile/scram, где все запихивают в одну текущую итерацию, но при этом все на каждом столбе пишут как правильно менеджить проекты :-D
Ну, вовлечённость - по мне это желание сотрудника сделать хороший продукт, отсутствие банальной халатности (что как раз и означает "по совести"), понимание того, куда движется проект, да и вообще понимание предметной области большее чем его конкретная таска. И это не только к программистам, а ко всем людям. Например, пример про программистов и тестировщиков: был у нас десктопный проект и надо было напилить новую фичу. В фиче была форма с текстовыми полями и выпадающими списками. Были и требования от бизнес аналитика, в которых в том числе описана эта куча полей, а вот сортировку указали только для нестандартных полей, которые отличны от сортировки по алфавиту. Так вот в одном из таких полей был достаточно большой список, выгружаемый из БД. Ну и программист его не отсортировал, как выгружается - так и показывается. Пока отлаживался его это не смущало, потому что он смотрел не на сами данные, а загружаются они или нет. Тестировщик тоже это пропустил, хотя тестировал именно эту форму не один раз, как он сказал потом "потому что в ТЗ этого не написано". Нашел тимлид, который решил прощелкать проект перед выдачей заказчику и увидел жутко неудобный неотсортированный выпадающий список. Так вот, конечно, можно сказать, что во всем виноват бизнес-аналитик, который должен каждый чих прописать в требованиях, но вроде как тестировщики у нас называются QA, что означает контроль качества и именно они больше всего общаются с приложением и они-то могут подать голос и сказать "ребята, мне вот тут так неудобно и пользователю тоже будет, давайте хотя бы enhancement создадим". А по факту причина здесь - та же невовлеченность... Тестировщик не думал, что он делает, и как это должно выглядеть в реальной жизни, он следовал только тому, что написано; ему неинтересна работа, хочется денег и домой смотреть сериальчики. Поэтому, для меня вовлечённость - это не желание работодателя заставить всех пахать бесплатно, а желание работника сделать хороший продукт, за который не стыдно, внимательно относиться к своей работе и не бояться высказывать свое мнение об улучшениях. А почему-то многие мыслят, что им скажут - "ты предложил, ты и делай в свободное время". А про работодателей и пахать - вспомните, что вы тоже сторона трудовых отношений, и вы соглашаетесь на предложенные условия.В статье, кстати, по пахать откровенно ничего не нашла, наоборот в первом абзаце говорится о желании сделать хорошо, что никак не равно пахать ..
Не поверите, компания, в которой я проработала долгое время, имеет и хороший офис и бесплатные обеды, и зарплата и ноуты хорошие, полугодовые ревью с обратной связью, бонусы к зарплате за техлидство, ПМство и т.д., но все равно в какой-то момент компания резко росла, надо было много специалистов, планка приема опустилась, и появилась куча молодых людей 24-26 лет, которые, видимо, читали книги из серии "как не работать и получать больше". Они воспринимают плюшки как должное, а не как дополнительный стимул, и не выходят на работу потому что "не в ресурсе". Менеджеры и техлиды тоже из этих людей вырастают и тут начинается интересное - их цель не сделать качественный проект, а сделать его с "зелёным" статусом.