Видимо я плохо передал некоторые нюансы. Agile, потому что он позволяет адаптировать разрабатываемый продукт под нужны клиента/руководителя в самые короткие сроки, чем короче итерации, тем быстрее можно перекроить планы, а это нам и было нужно он «фреймворка» ведения проекта. Да, вы правы, для улучшения качества и быстроты нужно внедрять еще множество технических процессов разработки. У нас они внедряются параллельно тому, что описано в этой статье.
Я не в коем случае не говорю, что нужно действовать не честными методами. Но, в том числе и в статье, приведены методы, которые являются честными, но при определенной интерпретации и не должном применении могут быть восприняты сотрудниками, как ложь и ухищрения. Если к работникам, тем более в сложной ситуации, относиться по человечески, то и с их стороны будут некоторые поблажки.
Очень похоже на нашу ситуацию. Думаю такие «похожие» ситуации не редки в нашем мире, у меня много знакомых, которые также, как и в нашей компании выросли вместе со своими проектами, и они привязаны к ним, как к детям, тяжело, иногда не возможно бросить свое, иногда несуразное, детище.
На пункт 1. Все задачи требуют программистов высокого уровня, нанимать дешевых — больше времени потратим на обучение, уже проходили. На пункт 2. Другие расходы идут не от отдела IT, расходы только увеличиваются, повлиять на это нет возможности. На пункт 3. Тоже самое что в пункте 1, уже пробовали, очень много времени уходит у специалистов на разъяснение того, как нужно делать, зашиваются, не успевают кодить.
Из-за неправильного стратегического движения, менеджмент вынужден предпринимать меры, чтобы не терять свои «родные» проекты и людей, на выращивание которых потрачено много сил.
«Меры» — не в коем случае не обман, а то что помогает оставаться единым коллективом в сложной ситуации.
Не совсем с вами согласен. Наши разработчики (в большинстве своем процентов 75) делают свои проекты, за частую так, как им это заблагорассудится (естественно в разумных пределах), то есть они ведут его так как им это интересно, используют технологии, на которых хотят это делать. И говоря свои проекты, я подразумеваю, что разработчик за частую сам вносит предложения по функционалу, и после одобрения и планирования, он реализует свою фичу. Подводя итог, Разработчикам дается большая свобода в реализации проектов, и возможно, частично из за этого есть некоторые просадки в бизнесе, по этому уровень финансов бывает ограничен, и чтобы разработчик не захотел сменить работу на гораздо более оплачиваемую, приходится применять некоторые «тактики» работы с ним.
Некоторых разработчиков ну ни как терять нельзя. По этому приходится делать все, чтобы они оставались. Вариант с долей, и это проходили, и процент от проданных экземпляров. Но это не работает, если не чего нет. По этому приходится предпринимать другие меры.
Все уведомлено, бизнес в курсе. Все риски внезапных уходов известны. Но бизнес говорит: решайте проблемы. И как я уже говорил, уловки: помощь богов, танцы шаманов и т.п., на данный момент имеют некий результат. Уловки — не обман, а то многие меня не поняли.
Про темп, я полностью согласен. Но, темп только возрастает, с подачи руководства, амбиции/завоевание мира/супер интересные проекты, много чего можно написать еще. Соответственно расширение коллектива, в большинстве не it, и соответственно фонд зп раздувается разработка и производство не может покрыть всего этого.
Но ставится задача «беспрецедентной» важности, не повалить проекты, в которые годы выкладывались силы и души. И по этому, мне, как руководителю it-отдела, приходится применять различные меры.
PS. Повлиять на ситуацию раздувания, нет возможности.
В условиях трудностей, переходить к каким-то грубым методам, не есть хорошо, у нас удаётся удержаться из-за наличия интересных проектов, в которые вложено много души.
Вариант, но в нашем случае ведущий к потере работника, так как мы с сотрудником знаем реальную его стоимость. Это обсуждается и мы видим вместе с ним все места куда он может уйти. Я не в коей мере не говорю, что практики, которые описаны выше, являются удачными. Я говорю про то, что менеджеру в трудных условиях приходится делать все, чтобы сохранить интересный проект и команду, в том числе идти на ухищрения.
Вы меня не поняли, либо я не правильно все обьяснил. Со своими программистами я уже более 2х лет, за это время их численность увеличилась в 4-5 раз. Все это время у нас трудности: фин. и многие другие. И мое сообщение выше несло такой смысл: менеджер, при определенных трудностях/проблемах, должен делать все, если он дорожит своими проектами и коллективом. Мы со своими программистами обсуждаем все: реальную стоимость, возможности уйти куда-то и многое другое, но это и есть одна из, как тут назвали «Техник». Вот про такого рода отношения и ухищрения я говорил.
У нас один энтузиазм, ни чего не разводили, применяем скрам и пм-системы в разумных масштабах. Делается всё, чтобы разработчикам было интересно работать. Но идут урезания свыше и по этому приходится еще больше «работать» с разработчиками, чтобы они не разбежались.
У каждого своя работа, разработчик — разрабатывает, менеджер — пытается предпринять все меры для того, чтобы разработчик мог спокойно кодить. А за частую менеджменту приходится идти на всякие разные ухищрения, потому что сверху его обрезают безбожно. Или у вас другое видение ситуации? Может быть я просто не понял ваш комментарий.
Блин, а часть из этого приходится делать для того чтобы удержать своих программистов. Работодатель не может позволить зарплаты больше, но ради осуществления интересных проектов в срок приходится идти еще и на более изащренные методы. Но радует, что большинство задач для разработчиков, удаётся организовать в интересном ключе.
Да и менталитет не позволяет, все хотят знать точные сроки разработки, нам пока не удается доносить до заказчиков, что так у них больше шансов получить более подходящий для них продукт. Все жертвуют своим «счастьем», ради этого мифического знания сроков.
Первое хорошо заходит, если работать полностью по agile, иметь ПО, который представляет заказчика и вносит грамотные коррективы на результат выполнения пользовательских хотелок, сейчас многие компании ориентированны на гибкую и итерационную разработку. Но мы столкнулись с проблемой: наши заказчики не готовы работать по agile, им подавай старый добрый «водопад». Но свои проекты мы пытаемся перевести на гибкую систему разработки.
10. Поощряйте тех, которые много предлагает идеи, но не исполняет их. Ведь руководителю любят тех, кто преподносит много полезных идей по нововведениям. Хорошо же когда люди хотят улучшить свою работу и работу людей вокруг себя, но плохо, что ни кто ни чего из этого не делает.
Последствия. Много разговоров ни о чем, работники будут только трепаться, но не решать задачи. Ведь они будут считать что они преподносят много идей и они инициативные. А это — инициативность, качество, которое я чаще всего сейчас вижу в резюме.
На пункт 2. Другие расходы идут не от отдела IT, расходы только увеличиваются, повлиять на это нет возможности.
На пункт 3. Тоже самое что в пункте 1, уже пробовали, очень много времени уходит у специалистов на разъяснение того, как нужно делать, зашиваются, не успевают кодить.
Из-за неправильного стратегического движения, менеджмент вынужден предпринимать меры, чтобы не терять свои «родные» проекты и людей, на выращивание которых потрачено много сил.
«Меры» — не в коем случае не обман, а то что помогает оставаться единым коллективом в сложной ситуации.
Подводя итог, Разработчикам дается большая свобода в реализации проектов, и возможно, частично из за этого есть некоторые просадки в бизнесе, по этому уровень финансов бывает ограничен, и чтобы разработчик не захотел сменить работу на гораздо более оплачиваемую, приходится применять некоторые «тактики» работы с ним.
Но ставится задача «беспрецедентной» важности, не повалить проекты, в которые годы выкладывались силы и души. И по этому, мне, как руководителю it-отдела, приходится применять различные меры.
PS. Повлиять на ситуацию раздувания, нет возможности.
Последствия. Много разговоров ни о чем, работники будут только трепаться, но не решать задачи. Ведь они будут считать что они преподносят много идей и они инициативные. А это — инициативность, качество, которое я чаще всего сейчас вижу в резюме.