Для тех, кто не умеет формулировать сразу то, что он хочет ТЗ - это проклятье. Соглашусь, что с такими нужно писать ТЗ самостоятельно исключительно для того, чтобы самому понимать объем работ и выстраивать разработку в соответствии с этим ТЗ. А все хотелки сверху - через доп ресурсы или извините, этого не было на старте. Гибкость - это хорошо, но вот твердят в аджайл скраме, мол "Сотрудничество с клиентом важнее согласования условий контракта" и "Готовность к изменениям важнее следования плану" и многие это понимают так, что можно тупо положить на план и на условия контракта. Кто-то такую лапшу кушает и потом страдает, но я вот много собак уже на таком скушал.
Словно боженька ниспослал. Сколько раз мы с тобой обсуждали эти вещи) Поздравляю с тем, что ты решилась, наконец-то, написать про это статью! Уверен, инженерное сообщество оценит!
вообще я давно заметил тренд на мультискилловость среди инженерных специальностей, особенно если дело касается стартапов. когда работал в корпе, то всегда под каждый чих была своя команда, а тебе надо было разве что кнопку нажать, чтобы запустить процесс. другое дело - стартап. сам себе и девопс, и безопасник, и тестировщик :)
Вопрос исключительно в регулярности таких вещей и тому, насколько это подходит для вас. Не подходит ни в каком виде - идём в другую компанию. Лично я отвечал отказом на любые попытки припахать меня к дежурствам до тех пор, пока это было для меня крит фактором.
судя по всему всё к этому и шло. насчёт ребячества - согласен, не бывает людей незаменимых. но одно дело, когда уходит один человек, а другое - когда запускается целая лавина уходов и при этом экспертизы не остаётся совсем никакой внутри компании.
Добрый день! Оплачиваемая переработка - это как раз про мотивацию) Где-то это финансовая составляющая, а где-то страх быть не как все или страх того, что выкинут на мороз, если ты скажешь, что что-то идёт не так.
очень интересно, а что случилось после вашего ухода в компании? у меня тоже бывали такие моменты ещё в инженерные времена - когда ты сильно перерабатываешь, но это воспринимается, как норма. и в итоге я возненавидел не просто компанию, а отрасль в целом, потому что компаний с поlобным отношеинем было большинство. и теперь я в IT)
Для тех, кто не умеет формулировать сразу то, что он хочет ТЗ - это проклятье. Соглашусь, что с такими нужно писать ТЗ самостоятельно исключительно для того, чтобы самому понимать объем работ и выстраивать разработку в соответствии с этим ТЗ. А все хотелки сверху - через доп ресурсы или извините, этого не было на старте. Гибкость - это хорошо, но вот твердят в аджайл скраме, мол "Сотрудничество с клиентом важнее согласования условий контракта" и "Готовность к изменениям важнее следования плану" и многие это понимают так, что можно тупо положить на план и на условия контракта. Кто-то такую лапшу кушает и потом страдает, но я вот много собак уже на таком скушал.
Словно боженька ниспослал. Сколько раз мы с тобой обсуждали эти вещи) Поздравляю с тем, что ты решилась, наконец-то, написать про это статью! Уверен, инженерное сообщество оценит!
звучит как план для новой статьи! спасибо!
вообще я давно заметил тренд на мультискилловость среди инженерных специальностей, особенно если дело касается стартапов. когда работал в корпе, то всегда под каждый чих была своя команда, а тебе надо было разве что кнопку нажать, чтобы запустить процесс. другое дело - стартап. сам себе и девопс, и безопасник, и тестировщик :)
Круто! Никогда не думал об ИИ с этой стороны) Спасибо!
Автор, ты просто красавчик! Ты не поверишь, как такие статьи вдохновляют тех, кто еще только начинает свой путь в разработку! Успехов тебе!
Я не знаю, что там ваша мама думает, но я думаю что если есть болезнь депрессия, то нужно идти к специалистам, а не сидеть на рабочх звонках.
Я уже был у психиатра после того, как у меня фляга свистела на почве работы, я знаю о чем говорю.
Вы точно мой пост читали?
Вопрос исключительно в регулярности таких вещей и тому, насколько это подходит для вас. Не подходит ни в каком виде - идём в другую компанию. Лично я отвечал отказом на любые попытки припахать меня к дежурствам до тех пор, пока это было для меня крит фактором.
исправлено! (не без вашего напоминания :D ) я свои обещания держу!) :D
А какие есть альтернативы? Совсем без iter оставлять?
судя по всему всё к этому и шло. насчёт ребячества - согласен, не бывает людей незаменимых. но одно дело, когда уходит один человек, а другое - когда запускается целая лавина уходов и при этом экспертизы не остаётся совсем никакой внутри компании.
прописные истины из детства начинают играть по-новому во взрослой жизни)
Добрый день! Оплачиваемая переработка - это как раз про мотивацию) Где-то это финансовая составляющая, а где-то страх быть не как все или страх того, что выкинут на мороз, если ты скажешь, что что-то идёт не так.
спасибо! про воспоминания - согласен)
очень интересно, а что случилось после вашего ухода в компании? у меня тоже бывали такие моменты ещё в инженерные времена - когда ты сильно перерабатываешь, но это воспринимается, как норма. и в итоге я возненавидел не просто компанию, а отрасль в целом, потому что компаний с поlобным отношеинем было большинство. и теперь я в IT)
тут вопрос гораздо глубже - школы не готовят человека к выбору того, кем он хочет стать
Спасибо большое! Про узость специалитета - отличная мысль, обдумаю её
я готов платить и полную стоимость за товар или услугу, если она формирует у меня правильные ожидания и даёт то, что обещает
мне в телегу)))