Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 12
Ну написано очень все красиво и хорошо!
Вообще я все еще не понимаю - неужели некоторые руководители приходя в такую должность вообще не осознают, что их задача быть тем самы организатором процесса работы своего отдела/управления/департамента?
Я это к тому, что вот даже все это прочитав (а в частности итоги, которые вы подвели) сидишь и думаешь - а так разве это и не должно так быть?
Ну то есть делегирование, организация рабочего процесса, мотивирование подчиненных и т.д. и т.п.
Я ни коем случае не принижаю заслуги Автора статьи. Все по делу!
Просто мне всегда казалось, что то, что тут описано (прости меня хоспади) "базовый минимум"?
Просто я прошел через примерно 3-4 отдела в которых было всякое и наверное одна из базовых вещей, которые я понял - "как корабль назовешь - так и он и поплывет". Ну в нашем случае, как работу организуешь - так и будешь работать.
Согласен с вами. Но почему то даже в компаниях выше среднего, к ит отделу отношение как к ребятам которые и клавиатуру поменяют и ЕРП внедрят. И зачастую учредители не задумываются том, что нужно строить организацию отдела. И либо ростить из текущих технарей - РП, либо нанимать кого-то со стороны.
Тут тоже соглашусь. Что менеджеры или даже начальники начальников достаточно скептически относятся к IT ребятам. Потому что будем честны: там люди зачастую попадаются 40+ для которых компьютер это что-то страшное. Я сейчас говорю не про всех, ни в коем случае! Просто лично мне приходилось сталкиваться с людьми, которые меня спрашивали где буква "ё" на клавиатуре. И да, я понимаю, что они сидят на своих должностях не чтобы знать, где буква "ё", а чтобы бизнесу 6 значные суммы приносить. Но суть я думаю вы поняли.
И да, таким людям приходится именно объяснять через разного рода презентации и графики утверждения: "вот для этого нашему отделу нужно то-то и то-то".
Обычный пример с внедрением ЕРП даже вызывает у них "страх" и "недоверие". Потому что "не, ну а че. В ексель вон все у вас же работает, че вам надо?".
Ну а так да. Если мы говорим о руководители отдела, который пока не имеет в подчинении еще других, своего рода "начальников" - то тут уже все зависит напрямую от него.
так то, в компания хорошо бы регулярно проводить курсы компьютерной грамотности для людей, у которых компьютер основной инструмент. Что бы умели экселем пользоваться нормально) ну и остальными инструментами, которые вводите, что бы они хотя бы знали что так можно сделать, и если нужно попросили помочь.
Прямо завидую. Когда я несколько раз пытался делать тоже самое результат был примерно нулевым.
Только не в роли ИТ директора, а руководителя проектного офиса. То есть без права бюджета, найма и увольнения. Я понял что так это не работает и ушёл в архитекторы.
Причины: сопротивление изменениям (даже гильдии целые были которые пора полностью увольнять), отсутствие поддержки руководством (вот, сомнительно что без прямой и жёсткой поддержки гендиректора получилось бы продать каталог услуг IT-отдела с ценником потому что неясно в чём измерять цену для бизнес подразделений - прямая цена в рублях не работает, а скрам оценки приводят к спорам), война бизнес подразделений, мой мягкий характер.
Насчёт оценки автором изначальной ситуации как нулевой позволю себе усомниться. Из-за отсутствия описания проблем и сопротивления статья кажется что автор - Трамп - спаситель нации. И из-за этого статья бесполезна.
Делай хорошо, не делай плохо. Вот что я прочитал.
Ограничьте WIP — не более 3 задач на человека одновременно
Я б уточнил -- не более 1 задачи
Это часто рекомендуется; однако на практике >1 задачи дают возможность отойти от одной, если произошла задержка (по любой причине: внешняя задержка, когнитивная усталость от задачи, зависимости задачи), и переключиться на другую. Такая гибкость всегда удобнее.
Со временем я пришёл к выводу, что 1-2 задачи одновременно наиболее удобны, строго 1 задача - слишком жёстко (и появляются лишние действия по судорожной смене статусов задач, когда возникают проблемы с текущей задачей, чтобы соблюсти правило 1 задачи), а 3-4 одновременных несвязанных задачи уже дают заметную внутреннюю нагрузку (муки выбора) по их приоритезации. Поэтому, хотя я и не ограничиваю формально число задач в статусе "выполняется", стараюсь следить за тем, чтобы в команде одновременных задач на человека было не больше 2-3, в идеале - 1-2.
Отдает нейронкой, но видимо сеткой правили текст уже написанный.
Ноги растут из одного - способность, возможность и желание людей идти на диалог, если речь про организационные вопросы внутри команды. То ли мне везло, то ли что, но в 7 компаниях такое было лишь в 2. В остальных тупо по ребрам получаешь. В лучшем случае, игнор. Даже если как-то наглядно представляешь свои идеи.
"Вкладываться в обучение" это что-то на японском в текущих реалиях, потому что все за свой счет и за свое личное время почти везде. Даже просто подменторить из коллег никто не берется. Особенно (как в моем случае) ты QA, а просишь поделиться опытом разработчика (и это были не вопросы про объяснение смысла жизни, а небольшие штуки). И еще кое-какие нюансы, которые объяснят 90% нашей жизни личной и рабочей. Но, как ни странно, за 9 лет работы в ИТ я всего с 1-2 людьми до такой сути докапывался.
Случай из жизни, 2024 год: банк, с зарубежным участием (экспаты все уехали, но костяк коллектива тот же), внедрены заявки, планирование, отчётность и всё такое прочее - но зам.директора по персоналу каждые 10-15 минут прибегает к начальнику отдела 1С (коллектив 5 человек) и стоит за спиной рассказывая что именно надо поправить в очередном отчёте, при этом примерно такая же ситуация с начальницей отдела по расчёту зарплат (почти заместитель финансового директора) - только бегать уже надо к ней. Два года борьбы результат не дали - эскалация на финансового директора, скандалы, эмоции и всё такое прочее.
Типичная история успеха при внедрении скрама, неплохо.
Слышал мнение, что скрам плохо подходит для поддержки из-за спринтов (т.к. со спринтами невозможно что-то реализовать/исправить в предельно короткие сроки, минимальное время получается ~1.5 спринта). Как вы это обошли?
Реализовали это так:
Все обращения, не важно это ли либо что-то не работает либо что то нужно доработать, ставятся через заявку. Первая линия квалифицирует таску. Если это задача на разработку в битриксе меняется Группа и это сразу падает в бэклог скрама. Дальше анализ задачи, приоритет и в спринт. Выше в комментарии вы правильно сказали, что если целый день сидеть над одной задачей мозг закисает, по этому на утренних дейликах мы смотрим если есть небольшие задачи и скрам мастер подсвечивает их и дает приоритет. Пока так справляемся.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От хаоса к системе: история трансформации IT-отдела за 7 месяцев