Помогите научиться укладываться в сроки

Здесь мы обсуждаем вопросы совместной работы в команде и с командами (Scrum, Kanban, TOC и прочий Lean)
zabr
Сообщения: 6
Зарегистрирован: Чт ноя 24, 2016 9:17 pm

Помогите научиться укладываться в сроки

Сообщение zabr »

Добрый день форумчане, хотел поделиться наболевшем ну и вдруг кто что посоветует.
Общая проблематика: не укладываюсь в сроки. Почти постоянно.

Дано:

Команда: Лид, джун и миддл.
ИТ Ландшафт:
100+ серверов с ERP, наша ИС (1 сервер + 1 тестовый плохой) в которую консолидируются данные,
разные службы (штук 10, там гео, репликация данных на те же 100 серверов), взаимные интеграции.

1) Поток задач которые зовутся проектами от 8 до 40-(~?~) ч емкостью каждое, приходит по 2-5 новых в неделю. Проект дробится на 4 части (разработка тз (аналитик отдельный), реализация (член команды), тестирование (член команды+аналитик), перенос в боевую).
2) Поток инцидентов (багов и проблем (наапример "почему у меня не видно что я проходил вчера утром вовремя", расскажите как строится вот эта цифра) обьемом в 20-30ч в неделю (выяснено опытным путем).
3) Потоки 1,2 приходят через канал Service DESK.
4) Поток почты с задачами и проблемами мелкими от руководства (2-10 писем в день)
5) Поток почты недружелюбных дивизионов у которых продолбились сроки или не можем их оценить потому что "ХЕРАЧИМ Б****"
6) Поток почты с вопросами и проблемами тех кто не знает о потоке №2. (1-5 шт)
7) Поток всяких рассылок от сервера консолидации в котором оно либо живое либо полумертвое.
8) Поток телефон корпоративный мобильный (периодически включаю, приходит 5-10 звонков, вык**** *****. )
9) Поток совещаний собеседований и давайте обсудим (1-2 в день).
10) Поток писем (небольшой 1-2 в месяц) от пользователей, ввиду изменений схемы данных в своей ERP ерпшниками и нас не уведомили ( иногда до 3х дней исправляем вдвоем )

Текущая ситуация:

Миддл сидит на потоке №3.
Джун на (~?~) проекте из потока №1, также закреплено одно из направлений из потока №1.
Лид по мере приоритезации еженедельной выполняет остальное.

Если из потока № 6 идет письмо руководителю лида он получает волшебный пендель и приоритезацию, который уже не помогает.
Гарантировано продолбано в потоке №1 при двух месячном планировании 30-50%, при месячном - 30%, при недельном - 30%.

Варианты решения:
1) разгрузить лида и нанять еще 2ух человек на 2 направления из потока 1 - в бюрокартической урне.
2) изменить систему планирования на ту которая учитывает зависимости и более мелко можно дробить задачи (MS Project+TFS) с коннектором самописным к системе потока №1 - долго - в бюрокоатической урне
3) проводить все потоки через систему потока №1 - просто нет.
4) ввести Agile, SCRUM - планировать на одну неделю и не говорить сроки заказчикам на целиковый проект - мы особенная компания (рук)
5) Уволится - под вопросом...
6) Нанять тех поддержку на поток №2 - в бюрокоатической урне
7) Увеличить скорость разработки за счет изменения железа (разнесения одного на 4) - дорого - в урну.


Результаты:
Срокобоязнь, нет мотивации к работе ...
Желание хоть что то изменить пока привели к установке системы мониторинга
(втайне от админов, которые нас не предупреждают когда у нас что то ломается, но не за что нам не дадут изменить их систему),
постепенно ее модернизирую, да я лид...
Последний раз редактировалось zabr Ср ноя 30, 2016 9:34 am, всего редактировалось 3 раза.

zabr
Сообщения: 6
Зарегистрирован: Чт ноя 24, 2016 9:17 pm

Re: Хочется поменять ситуацию

Сообщение zabr »

Мысли...

Есть мысль проекты из потока задач при планировании еженедельном дробить на ясные куски (пусть потеряю 1-3 часа на проект),
может стоит кусочки пихать в другую систему - YouTrack например. Тогда возникает проблема того что неверные были первоначальные сроки...

Если заниматься ежедневным разбором и дроблением проектов будущих то возникнет проблема того,
что в них будут кривые ТЗ ( не успеют отработать аналитики ).

Наверное оценка по срокам должна даваться после работы аналитика и декомпозиции как мне кажется,
но это не удовлетворит заказчиков и руководство (им нужно быстро ответить заказчикам срок и ответственного).

Аватара пользователя
Андрей Степенко
Сообщения: 133
Зарегистрирован: Пт июл 31, 2015 1:05 pm
Контактная информация:

Re: Хочется поменять ситуацию

Сообщение Андрей Степенко »

Так бывает всегда. Пока поток задач не декомпозирован он кажется "тут чуть" и "там чуть" и все срастётся. Пример очень простой чтобы было понятно, мы когда квартиры-дома покупаем то все это делается на последние деньги. А на ремонт уже не хватает. Нужна смета или запас. Но жадность не дает
Ощущение длительности задачи, (пресловутая оценка) и длительность выполенения - это сущность из параллельных пространств. :) Даже физически их измеряют два разных полушария. Поэтому не удивительно, что попадаете "в молоко". А поскольку с оценками расставаться не хочется возникает такая затраханность сроками. Это ж мы оценили как же отказаться? Как же признать что оценка была не верной? Еще раз оценка - это оценка, а длительность - это длительность. (Я не про пмбуковские термины)
Нужно мерить "линейками". Делать стандартные названия задач, типизировать и т.п. Когда накопится статистика, то можно будет оперировать цифрами, на которые можно опираться. Для этого понятное дело кто-то главный должен эту картинку складывать. Что есть типовые задачи? Как из типовых задач собриаются "проекты" или "инциденты". (Опять же не путать с ITSM-терминами)
По факту (не заранее) просто продиагностировать. Растет количество техдолга, значит вам не хватает мощности. Т.е. количество людей должно быть увеличено. Но при этом если докомпозицию не довести до уверенности, что 90% задач у вас имеет оценки из правильного полушария мозга, то будет не намного лучше. Хотя можно снизить стресс. И вообще процесс комплексный. Две зависимых переменных по крайней мере.
Декомпозицией должен заниматься главный кто-то. Даже если аналитик чего-то предложит, то его оценки нужно утвердить лиду. Пока главный не возьмется за то, чтобы отвечать за базар, все будет так же как и было.
Если коротко - нужны типовые маршруты. Желательно, чтобы их было от 90% общего объема работы.

zabr
Сообщения: 6
Зарегистрирован: Чт ноя 24, 2016 9:17 pm

Re: Помогите научиться укладываться в сроки

Сообщение zabr »

Насчет типизации, не выйдет как мне кажется примеры:
Сегодня надо сделать отчет сделав попутно сервис который интегрируется с системой виалон (гео мониторнг)
А Завтра мы пишем сервис с двухфакторной авторизацией для внешних запросов через кроссдомен (какой то внешний сайт)
А послезавтра надо переписать интеграцию с системой оптимум в части маршрутов супервайзеров.

У меня задачи повторяются в 10-20% случаев.
Косяки да есть повторы те которые и по 100-200 раз ((. - пока пересиливаю себя и ввожу вики постепенно.

Еще частую проблему сегодня заметил раз наверное в 20ый за 2 года работы - мы приступаем зачастую когда перед нами не сделали функционал или сделали неккорректно, а сроки уже усе ... завтра.

zabr
Сообщения: 6
Зарегистрирован: Чт ноя 24, 2016 9:17 pm

Re: Помогите научиться укладываться в сроки

Сообщение zabr »

Займусь декомпозицией основательно, спасибо.

Аватара пользователя
Андрей Титов
Сообщения: 207
Зарегистрирован: Ср сен 23, 2015 2:24 pm
Откуда: Калуга
Контактная информация:

Re: Помогите научиться укладываться в сроки

Сообщение Андрей Титов »

@zabr - насколько я себе могу представить вышеописанную ситуацию, то всё "это" сводится к регламенту выполнения работ, который разрабатывается и утверждается до того, как "всё" начинает приходить в движение.

Почему у вас вначале запускаются проекты и сопутствующие задачи, а потом начинается размышление о регламенте - это чисто вопрос менеджмента, он даже не технический. А вы стараетесь подойти технически.

И да - у вас в описании всё поток, то есть сложность в разделении - "мухи отдельно - котлеты отдельно". Это тоже управленческая задача.

И , собственно, на данный момент - приведение всей этой массы в порядок и есть ваша обязанность, то есть поставьте это на первое место, а технические вопросы делегируйте и всё наладится.

При этом, если есть вышестоящее руководство и оно скажет, что ваша задача техническая, а не регламенты менять в организации - то это хороший повод задуматься о вашей роли и ценности в данной системе.
Кто понял жизнь - тот не спешит

comm
Сообщения: 44
Зарегистрирован: Вт окт 06, 2015 12:32 pm
Откуда: Saint-Peterburg, RU
Контактная информация:

Re: Помогите научиться укладываться в сроки

Сообщение comm »

@zabr

1. Сначала сделать 1 поток.
2. Если есть Service DESK, то все зарулить на него, почту, чат. Автозаявки если упало. Заявки по звонкам отправлять в сервис деск.
3. от 8 до 40 часов это не проект. это задачи.
4. Мерять метрики : скорость решения, время висения в очереди. время потраченное.
5. После 2-4 недель прогона провести ретреспективу, оценить метрики. распределение задачи по времени решения.
6. Показать объективную картинку цифр руководству, обсудит SLA , поднять вопрос о не достатке ресурсов.
С уважением, Алексей Васильев. http://bipulse.ru

Аватара пользователя
Sergey Martynenko
Сообщения: 20
Зарегистрирован: Пт май 20, 2016 1:39 pm
Контактная информация:

Re: Помогите научиться укладываться в сроки

Сообщение Sergey Martynenko »

comm писал(а):@zabr
1. Сначала сделать 1 поток.
2. Если есть Service DESK, то все зарулить на него, почту, чат. Автозаявки если упало. Заявки по звонкам отправлять в сервис деск.
3. от 8 до 40 часов это не проект. это задачи.
4. Мерять метрики : скорость решения, время висения в очереди. время потраченное.
5. После 2-4 недель прогона провести ретреспективу, оценить метрики. распределение задачи по времени решения.
6. Показать объективную картинку цифр руководству, обсудит SLA , поднять вопрос о не достатке ресурсов.
3 - согласен. Причем атомарные и оценивать их трудоемкость - это прямое нанесение ущерба фирме.
4. время потраченное - в сад. Time to market - да, отличная метрика. Не самая важная, но вторая по важности.
6а. SLA как его сейчас пишут тоже в сад. Работайте по картам Шухарта.
6б. По поводу недостатка ресурсов. Есть всего два хороших состояния. Когда ресурсов недостаток и когда ресурсов избыток. Нужно договориться о том в какой модели вы будете жить.

Есть несколько способов изящно выстрелить себе в ногу:
* KPI
* Таймшиты
* Оценка трудоемкости атомарной задачи

Фулхауз можно получить несколькими разными способами. Напримемер:
* SLA
* четвертое правило воронки в варианте "стажер учит стажера"

Аватара пользователя
Андрей Степенко
Сообщения: 133
Зарегистрирован: Пт июл 31, 2015 1:05 pm
Контактная информация:

Re: Помогите научиться укладываться в сроки

Сообщение Андрей Степенко »

zabr писал(а):Насчет типизации, не выйдет как мне кажется примеры:
Сегодня надо сделать отчет сделав попутно сервис который интегрируется с системой виалон (гео мониторнг)
А Завтра мы пишем сервис с двухфакторной авторизацией для внешних запросов через кроссдомен (какой то внешний сайт)
А послезавтра надо переписать интеграцию с системой оптимум в части маршрутов супервайзеров.
Очень интересные названия задач. Просто прямо так руки сразу зачесались сразу в бой.
Когда я учился в институте еще были перфокарты на старых компьютерах. И старые дядьки ведущие у нас программирование очень часто повторяли, что нарисовать блоксхему и обсужить архитектуру будет не только экономия, но и понимание из каких типовых блоков состоят наши программы. На первом курсе даже не пускали к компьютеру, если не можешь внятно описать как будет работать программа. Но мы-то прорывались.

Постановка задачи в первом посте показывает, что это вроде задача "на минуточку" - помогите разобраться. Я могу ошибиться, но мы же тут в форуме. Поэтому не обессудьте за "диагностику по фотографии".
Так вот ваша задача системная, а не узко функциональная. Как точечная застройка в Москве. Вроде воткнуть девятиэтажку можно, но садиков и магазинов не хватит. А и хер с ними! Если нет понимания, что такое системная задача, то нет и ценности её решения. Соответственно никто не будет защищать это решение от разного рода любителей "рраз и на минуточку" воткнуть вам еще пару-тройку задач.

Собственно что и происходит в формиулировках ваших "интересных названий задач". Почему происходит? Потому что вам не важно, чтобы была системность. Поэтому конда приходят дядьки и говорят надо срочно, то вы и не замечаете, что будет жопа. Вы же сами такие же как эти дядьки - не системные. В результате все довольны! Одни чуствуют, что задача не будет сделана в срок, но теперь мяч уже не на их стороне.

И потом, конечно сюда в форум и "на минуточку" надо разобраться. Это примерно как вакансия сисадмина, который должен внедрить сапР3. Ребята, это не серьезно. Ну не позорьтесь этим детским "шапкозакидательством".
В "консерватории" проблемы. За пять минут типизация не выйдет конечно, это к бабке не ходи.
Опять же и тема форума "как доводить дела вместе"...

И для отчета и для сервиса есть какая-то оценка. И какая-то приоретизация вместе с теми задачами которые уже есть. Правда? Ресурсы-то которыми вы ваяете эти сервисы и эти гео-двухфакторные-виалон-твою-за-ногу они не бесконечные? А значит с одних задач надо людей снять и на другие поставить. На основании чего? Ну не важно, тогда чего разговор-то. Какое целеполагание, такая и типизация. Если есть цель, чтобы она(типизация) не получилась, то она и не получится. И к дедке не ходи. :) Есть даже народная мудрость, что хороший руководитель проекта, который умеет говорить "нет". И слать всех далеко с новыми задачами.

А вот когда типизация начнет получаться, тогда ваши начальники попробуют вас уволить потому, что вы им малину ломаете. Поэтому может и хорошо, что она не получается. Так и живем.

comm
Сообщения: 44
Зарегистрирован: Вт окт 06, 2015 12:32 pm
Откуда: Saint-Peterburg, RU
Контактная информация:

Re: Помогите научиться укладываться в сроки

Сообщение comm »

Sergey Martynenko писал(а): Есть несколько способов изящно выстрелить себе в ногу:
* KPI
* Таймшиты
* Оценка трудоемкости атомарной задачи

Фулхауз можно получить несколькими разными способами. Напримемер:
* SLA
* четвертое правило воронки в варианте "стажер учит стажера"
Сергей, про KPI я ни где не говорил. не нужен такой KPI, и KPi по времени конечно вреден. Но оценка фактического времени к оцененному, показывает ошибку оценки и поднимает источник для TTM - "А чего так долго?" , что добавляет аргументации для добавления ресурсов ресурсов.

Основное правило: Решать проблему - а не человека. Если скорость роста объема выше чем скорость реализации это просто факт. Но эту скорость нужно как-то оценивать.
С уважением, Алексей Васильев. http://bipulse.ru

Ответить