Комментарии 14
С нами делают ровно то, с чем мы согласны, даже внешне.
Работодателю же выгодно держать всех в неведении, чтобы низкооплачиваемые сотрудники не просили больше.
Это работает, когда у вас в стране инфляция 2-3%, а разрыв в зарплатах не слишком заметен.
У нас в стране подобная политика больше похожа на карго-культ и работает в обратную сторону, все думают, что их коллегам платят намного больше, а их недооценивают.
Когда в действительности вообщем-то так и есть. У нас в компании даже запрещено делится своими задачами и зарплатами).
Работодатели экономят таким образом, создавая сложные системы мотивации - затрудняющие определить настоящую зарплату и меняют подобные мотивации для каждого конкретного работника в силу его незнания ТК или незаинтересованности в борьбе за зп.
Невозможность оценки R&D-задачи.
А мне говорили, что хороший исследователь всегда знает, сколько займёт то или иное исследование, а если не знает, то может сказать, через сколько он это узнает. Это что же, мне врали, получается? /s
Кроме шуток, я правда с таким сталкивался.
Как ни странно, RnD задачи тоже можно и нужно оценивать. Не в терминах "я найду решение за 4 дня", а в терминах "мы готовы выделить на исследование 4 дня". Во втором случае по истечении этого времени должны быть зафиксированы промежуточные результаты и принято решение о продолжении или отказе от дальнейшего RnD. В противном случае такое исследование рискует превратиться в бесконечную задачу по итогам которой будет сказано: "не шмогла я".
Спринты не так уж и плохи, если нет необходимости соблюдать бюрократические формальности с закрытием всех задач в конце и чрезмерным разбиением на подзадачи. Они структурируют процесс планирования в проектных командах: вместо абстрактной задачи "распланировать реализацию такой-то информационной системы", можно верхнеуровнево распределить задачи по выведению различного функционала и детально расписать только ближайшие поставки. Короче – это удобный фреймворк для планирования методом набегающей волны.
А без самого планирования в проектной разработке никак – PM должен выбить бюджет на заранее определенный срок.
Они (спринты) структурируют процесс планирования ... детально расписать только ближайшие поставки.
А без самого планирования в проектной разработке никак
А не получится это решить канбан-доской, когда задачи нужно брать по приоритету? Менеджер может планировать и детально расписать только самые приоритетные задачи.
На мой взгляд, в планировании должен участвовать разработчик, чтобы не получилась ситуация, когда сроки спускают сверху, а команда должна перерабатывать, чтобы в них уложиться. Менеджер не может знать все тонкости разработки. Много раз встречал такую ситуацию: руководство считает, что "надо всего одну проверку поменять", а на самом деле это требует создания совершенно нового функционала. В итоге для внедрения изменения надо все сроки сдвинуть каскадом или заставить команду работать сверхурочно. По моему опыту выбирают второе.
Но разработчика лучше на планирование слишком часто не отвлекать, так что делать его стоит по заранее оговоренному расписанию. А в качестве такого расписания как раз подходят спринты.
Канбан-доска – хорошее решение, но немного для других целей. Она хороша для синхронизации людей внутри команды и распределения задач. А планирование, как мне кажется, должно синхронизировать команду и менеджмент.
Хочется высказаться в защиту спринтов. Люди подсознательно не любят бесконечные процессы. Нам всегда нужны какие-то точки отсчёта. Поэтому существуют месяцы, кварталы и Новый Год — чтобы прерываться и начинать "с нуля".
Не знаю на счёт культа, меня тоже, как видимо многих, вводит в ступор собеседования и вообще отбор в компании. Но мне кажется тут все прозаичнее, бизнес боится нового из-за убытков, вот и шлепают как у всех, от собеседований до рабочего процесса.
Заговор разработчиков против корпораций: работа с командой