Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 63
Вот и молодец. Серьезно. Осталось только разруху в головах убрать, в виде нежелания прилагать усилия для изменений.
Раньше загоняли в бутылку. А Иван загоняет во флакон.:)
одно странно выглядит: почему окно о выполнении задачи сразу летит от исполнителя инициатору над головой ответственного? Зачем нужен ответственный тогда? Работал с одной системой, где были только связи исполнитель- начальник отдела, тк отделов было много и работа пересекается со смежниками, то часто надо было выдавать задания в другой отдел. для этого нужно было получить под заданием подпись руководителя своего отдела и отдать её начальнику другого отдела. Дальше если начальник соглашался с заданием, то отдавал задание исполнителю в своём отделе. Копии делались всем участникам и всем начальникам. Дальше исполнители сами между собой договаривались о работе но только о том, что было написано в задании. Оценкой работы всех отделов служила вовремя выполненная работа. Все работали на общий результат, а не на баллы как у вас предложено. Потом эту систему с человеческим взаимодействием между разными отделами заменили электронной версией с кучей надстроек из-за чего теплые отношения ушли а остались вымученные поля в программе. Уже давно там не работаю, но система утверждения всего в два шага, с пониманием всех сторон о чем речь, до сих пор кажется идеальной. Простой, но эффективной. С прокачкой софтскилс при выдаче заданий. С общением между отделами. Мне кажется поэтому люди не делают системы
Конкретно по флакону — кто-то из его разработчиков или внедренцев считал cost rate driver?
Какая экономическая выгода от этой системы, выраженная в рублях, долларах, иной валюте?
Какая экономическая выгода от этой системы, выраженная в рублях, долларах, иной валюте?
У одного из клиентов, тоже пересаживающихся на флакон, посчитана, но они строго-настрого запретили рассказывать какую-либо конкретику.
У нас самих флакон высвободил время — при том же уровне доходов от услуг мы реализовали несколько проектов по разработке (включая сам флакон). Проекты запустились недавно, поэтому доходы от них пока скромные.
У нас самих флакон высвободил время — при том же уровне доходов от услуг мы реализовали несколько проектов по разработке (включая сам флакон). Проекты запустились недавно, поэтому доходы от них пока скромные.
но они строго-настрого запретили рассказывать какую-либо конкретику.
Ну а как так? Это главный мотив для внедрения подобного рода систем. До тех пор пока владельцу «на пальцах» нельзя будет обьяснить, что внедрение такой системы позволит сэкономить N рублей, и покажет как именно это будет сделано.
Я о том же переживаю. Но тут палка о двух концах. Вокруг них полно конкурентов, с очень схожим бизнесом. Если конкуренты узнают, что можно, например, процентов на 40 за месяц приподняться, почти ничего не меняя, то конкурентное преимущество будет утрачено.
Я правильно прочитал, что клиент после внедрения флакона смог снизить косты на 40%?
Если кратко, то ахренеть и слабо верю.
Если длинно, то я тут же бежал бы с флаконом к конкурентам «смотрите, я вам такую штуку поставлю, закачаетесь, ваши расходы минимум на 20% упадут, а у одного из ваших конкуртентов (не скажу у которого) вообще на 40% упали, хотите? вот здесь подпишите...»
Если кратко, то ахренеть и слабо верю.
Если длинно, то я тут же бежал бы с флаконом к конкурентам «смотрите, я вам такую штуку поставлю, закачаетесь, ваши расходы минимум на 20% упадут, а у одного из ваших конкуртентов (не скажу у которого) вообще на 40% упали, хотите? вот здесь подпишите...»
не снизить косты, а выпуск увеличить при той же доле переменных и той же сумме постоянных затрат. Флакон — про то, как делать больше в единицу времени.
Опять не понимаю:
Все производственные сектора имеют друг на друга завязанную производительность. Ту главное, что каждый зависит от каждого: пока склад не оприходует сырье — оно не пойдет на производство (и количество принятого сырья зависит не столько от его размера, сколько от потребности рынка, то есть способности продать); пока производство не сделает продукт по определенной техкарте и со вполне очевидной производительностью — оно не уйдет на ОТК; пока ОТК не проверит, по вполне очевидной техкарте, с прогнозируемым % брака, продукт не уйдет на склад готовой продукции.
Я тут простейший процесс описал, и не понимаю — как флакон может повлиять на конечную производительность конкретного станка и оператора за ним? Или на производительность инженера по качеству?
Все производственные сектора имеют друг на друга завязанную производительность. Ту главное, что каждый зависит от каждого: пока склад не оприходует сырье — оно не пойдет на производство (и количество принятого сырья зависит не столько от его размера, сколько от потребности рынка, то есть способности продать); пока производство не сделает продукт по определенной техкарте и со вполне очевидной производительностью — оно не уйдет на ОТК; пока ОТК не проверит, по вполне очевидной техкарте, с прогнозируемым % брака, продукт не уйдет на склад готовой продукции.
Я тут простейший процесс описал, и не понимаю — как флакон может повлиять на конечную производительность конкретного станка и оператора за ним? Или на производительность инженера по качеству?
я говорил о выпуске продукции программистами.
А разработка точно должна на 40% быстрее фигачить?
Т.е. какой потребности отвечает цель получить от разработчика на 40% быстрее результат? И всегда-ли «быстро» означает «качественно»?
Иван, я второй раз при прочтении ваших комментариев вспоминаю два анекдота, первый про "… но есть нюанс" я здесь приводить не буду, а вот второй под спойлером.
Т.е. какой потребности отвечает цель получить от разработчика на 40% быстрее результат? И всегда-ли «быстро» означает «качественно»?
Иван, я второй раз при прочтении ваших комментариев вспоминаю два анекдота, первый про "… но есть нюанс" я здесь приводить не буду, а вот второй под спойлером.
Заголовок спойлера
Стоят на пригорке два быка, молодой и старый, и смотрят на пасущееся внизу в долине стадо коров. Молодой бычок, горячий, нетерпеливый, волнуется, рогом землю роет и обращается к старику: «Бык, а бык, давай быстренько спустимся вниз и поимеем в-о-н… ту рыженькую
коровку!!!
Старый отвечает медленно: „Нет! Мы этого делать не будем!“
Молодой успокаивается, но потом опять: » Бык, а бык, давай тогда быстренько спустимся вниз и поимеем вон ту черненькую…
В ответ звучит: «Нет! Мы этого делать не будем.»
Молодой (обиженно): " Ну что же мы тогда будем делать?"
Старый говорит с расстановкой: «Мы медленно спустимся вниз и поимеем все стадо»
коровку!!!
Старый отвечает медленно: „Нет! Мы этого делать не будем!“
Молодой успокаивается, но потом опять: » Бык, а бык, давай тогда быстренько спустимся вниз и поимеем вон ту черненькую…
В ответ звучит: «Нет! Мы этого делать не будем.»
Молодой (обиженно): " Ну что же мы тогда будем делать?"
Старый говорит с расстановкой: «Мы медленно спустимся вниз и поимеем все стадо»
Сейчас у приличных 1С франчей проблема — количество заказов превышает возможности имеющихся сотрудников, а новых сотрудников найти тяжело. Поэтому, преимущества ускорения на 40% для них очевидны.
Должна, или не должна, решает ЛПР, в зависимости от целей и стратегии бизнеса. Ситуаций разных много.
Вот простой пример — франчайзи 1С, отдел сопровождения, решает разовые задачи клиентов.
Поступает задача, ее кто-то оценивает в часах, договариваются с клиентом о конкретной стоимости.
Реальные трудозатраты, по факту, получаются выше — это статистические данные. Получается, человек тратит в месяц 168 часов, и производит, допустим, 100 оплачиваемых часов.
Садим на флакон, он начинает решать задачи быстрее, при сохранении того же уровня качества. Теперь он за 168 часов времени производит 168 оплачиваемых часов.
Доход вырос на 68 %, если я не ошибаюсь — и у компании, и у программиста. Постоянные затраты не подросли, доля переменных осталась прежней.
Вот простой пример — франчайзи 1С, отдел сопровождения, решает разовые задачи клиентов.
Поступает задача, ее кто-то оценивает в часах, договариваются с клиентом о конкретной стоимости.
Реальные трудозатраты, по факту, получаются выше — это статистические данные. Получается, человек тратит в месяц 168 часов, и производит, допустим, 100 оплачиваемых часов.
Садим на флакон, он начинает решать задачи быстрее, при сохранении того же уровня качества. Теперь он за 168 часов времени производит 168 оплачиваемых часов.
Доход вырос на 68 %, если я не ошибаюсь — и у компании, и у программиста. Постоянные затраты не подросли, доля переменных осталась прежней.
Если кратко, то ахренеть и слабо верю
Это главная проблема на данный момент. Потом решится как-нибудь, сейчас никто не верит.
Так не верят ИТ-шники на слово, им расчёты подавай — что было до, что изменилось, что стало после.
И обоснование еще требуется.
Из воздуха получается только… воздух.
Из воздуха получается только… воздух.
Какое ещё обоснование нужно, если расчёты покажут реальное улучшение целевых показателей на 40%, например?
— Я те как брат брату говорю — точняк тема, минимум на 40% твои эти… целевые показатели… улучшатся.
— Гражданин, перестаньте меня обнимать, присаживайтесь пожалуйста. А теперь расскажите, что именно подразумеваются под «целевыми показателями» и, главное, термином «улучшатся». Зиночка, еще кофе пожалуйста…
— Гражданин, перестаньте меня обнимать, присаживайтесь пожалуйста. А теперь расскажите, что именно подразумеваются под «целевыми показателями» и, главное, термином «улучшатся». Зиночка, еще кофе пожалуйста…
Потом могут и другие проблемы появиться.
Например, люди будут разбегаться из-за перенапряжения.
Кратковременно можно заставить человека выложиться на 200% и даже на 300%. А если он раньше ни черта не делал, то даже на 1000%. Но устойчивым показателем я бы это не назвал.
Например, люди будут разбегаться из-за перенапряжения.
Кратковременно можно заставить человека выложиться на 200% и даже на 300%. А если он раньше ни черта не делал, то даже на 1000%. Но устойчивым показателем я бы это не назвал.
Перенапряжения нет. Я на этой методике уже года три сижу. Эффективность растет, а работаю все меньше (по времени).
Чудес не бывает.
Эффективность должна откуда то браться.
Варианты:
— раньше эффективность была близка в 0.
— эффективность всех работников близка к 0, а флакон каким то удивительным образом это исправляет — вот нужно понимание каким!
-лично Вы очень и очень выносливый человек
итд
У меня вот нет понимания каким образом эта методика может увеличивать эффективность без перенапряжения.
То что средний Итшник работает на работе значительно меньше положенных 8 часов для меня не новость. Если флакон заставляет работать 8 часов — это один из вариантов повышения эффективности. И фактор будущего выгорания.
Очень много людей имеют обыкновение «откладывать на потом» и таким образом терять задачи. Флакон может выступать в роли дятла и заставлять «ставить эту долбаную галочку сейчас, а не через пол года» — это тоже положительно сказывается на эффективности работы коллектива в первую очередь и личной тоже.
Иван, попробуйте сформулировать за счет чего Флакон повышает эффективность. Но не как вы любите — на 7 экранов. А кратко по пунктам без воды.
Эффективность должна откуда то браться.
Варианты:
— раньше эффективность была близка в 0.
— эффективность всех работников близка к 0, а флакон каким то удивительным образом это исправляет — вот нужно понимание каким!
-лично Вы очень и очень выносливый человек
итд
У меня вот нет понимания каким образом эта методика может увеличивать эффективность без перенапряжения.
То что средний Итшник работает на работе значительно меньше положенных 8 часов для меня не новость. Если флакон заставляет работать 8 часов — это один из вариантов повышения эффективности. И фактор будущего выгорания.
Очень много людей имеют обыкновение «откладывать на потом» и таким образом терять задачи. Флакон может выступать в роли дятла и заставлять «ставить эту долбаную галочку сейчас, а не через пол года» — это тоже положительно сказывается на эффективности работы коллектива в первую очередь и личной тоже.
Иван, попробуйте сформулировать за счет чего Флакон повышает эффективность. Но не как вы любите — на 7 экранов. А кратко по пунктам без воды.
На счастье, у меня есть под рукой готовый список — оглавление курса/книги, которую пишу по флакону. Это примерно половина того, что есть в методике — методы, подходы, кейсы и рекомендации.
1. Где теряется эффективность?
Общее понятие об эффективности командной работы. Где она теряется, где ее ищут, и почему ничего не получается.
2. Измерение задач
Как, и зачем измерять задачи в чем-то, помимо часов.
3. Выбор задачи
Как лишить сотрудника выбора задачи, и почему это важно?
4. Матрица Эйзенхауэра
Простой метод выбора приоритетов выполнения задач.
5. Сроки выполнения задач – ставить или нет?
Рассмотрим влияние постановки сроков на реальную эффективность.
6. Управление жизненным циклом задачи
Почему это важно, как организовать, на что обратить внимание.
7. Правильное использование ограничений в работе с задачами
Использование Теории ограничений Голдратта в работе с задачами
8. Регулярный менеджмент
Зачем он нужен, и как его организовать.
9. Организация обсуждений и взаимопомощи
Как часто собираться, как управлять обсуждением, на чем акцентировать внимание.
10. Учет компетенций сотрудников и задач
Как, и зачем, учитывать компетенции сотрудников и задач.
11. Сопротивление – виды и последствия
Какие виды сопротивления бывают, и как они сказываются на эффективности.
12. Цели сотрудников и компании
Как, и зачем знать цели сотрудников, и использовать их на благо общей цели.
13. Мотивация
Что нужно изменить в системе мотивации, чтобы эффективность росла сама.
14. Методы преодоления сопротивления профессиональных мнений
Один считает так, другой – иначе. Как привести к общему знаменателю с пользой для дела?
15. Виды страхов и работа с ними
Почему важно понимать, чего боятся программисты. И что со страхами делать.
16. Повторное использование решений
Почему это важно и как организовать?
17. Каскад задач
Почему задачи одного контекста, если их делать подряд, выполняются быстрее?
18. Профиль команды
Как, и зачем знать сильные и слабые стороны команды.
19. Обратная связь от сотрудников
Как собирать, обсуждать и применять.
20. Контроллинг
Как, и зачем контролировать выполнение правил
21. Непрерывное повышение эффективности
Есть ли предел эффективности? Стоит ли останавливаться на достигнутом?
22. Система управления задачами
Основные требования, которым должна удовлетворять ваша система постановки задач.
23. Новые сотрудники
Как, когда и кого брать на работу? Как включать в командную работу?
24. Расширение границ
На что еще способны программисты 1С? Как вывести их на новый уровень и создать лучшую команду?
А эффективность повышается за счет вытаскивания головы из задницы. Достаточно коротко? :)
1. Где теряется эффективность?
Общее понятие об эффективности командной работы. Где она теряется, где ее ищут, и почему ничего не получается.
2. Измерение задач
Как, и зачем измерять задачи в чем-то, помимо часов.
3. Выбор задачи
Как лишить сотрудника выбора задачи, и почему это важно?
4. Матрица Эйзенхауэра
Простой метод выбора приоритетов выполнения задач.
5. Сроки выполнения задач – ставить или нет?
Рассмотрим влияние постановки сроков на реальную эффективность.
6. Управление жизненным циклом задачи
Почему это важно, как организовать, на что обратить внимание.
7. Правильное использование ограничений в работе с задачами
Использование Теории ограничений Голдратта в работе с задачами
8. Регулярный менеджмент
Зачем он нужен, и как его организовать.
9. Организация обсуждений и взаимопомощи
Как часто собираться, как управлять обсуждением, на чем акцентировать внимание.
10. Учет компетенций сотрудников и задач
Как, и зачем, учитывать компетенции сотрудников и задач.
11. Сопротивление – виды и последствия
Какие виды сопротивления бывают, и как они сказываются на эффективности.
12. Цели сотрудников и компании
Как, и зачем знать цели сотрудников, и использовать их на благо общей цели.
13. Мотивация
Что нужно изменить в системе мотивации, чтобы эффективность росла сама.
14. Методы преодоления сопротивления профессиональных мнений
Один считает так, другой – иначе. Как привести к общему знаменателю с пользой для дела?
15. Виды страхов и работа с ними
Почему важно понимать, чего боятся программисты. И что со страхами делать.
16. Повторное использование решений
Почему это важно и как организовать?
17. Каскад задач
Почему задачи одного контекста, если их делать подряд, выполняются быстрее?
18. Профиль команды
Как, и зачем знать сильные и слабые стороны команды.
19. Обратная связь от сотрудников
Как собирать, обсуждать и применять.
20. Контроллинг
Как, и зачем контролировать выполнение правил
21. Непрерывное повышение эффективности
Есть ли предел эффективности? Стоит ли останавливаться на достигнутом?
22. Система управления задачами
Основные требования, которым должна удовлетворять ваша система постановки задач.
23. Новые сотрудники
Как, когда и кого брать на работу? Как включать в командную работу?
24. Расширение границ
На что еще способны программисты 1С? Как вывести их на новый уровень и создать лучшую команду?
А эффективность повышается за счет вытаскивания головы из задницы. Достаточно коротко? :)
А эффективность повышается за счет вытаскивания головы из задницы.
Другими словами, если голова полностью в заднице, то флакон позволит вытащить ее оттуда на 40%.
… но это не точно. Станет понятно, когда внедрим.
ИМО это очень важно — чтобы сотрудники вытащили головы из задниц и начали наконец эффективно работать. Головы в заднице — одна из основных проблем в айти
Если бы только в ИТ…
Но на месте сотрудников стоило бы поинтересоваться: а зачем голову то вынимать? Чтобы прибыль у собственника повысить? Так пусть он и вынимает. По опыту премии получают не рядовые итшники, а большие начальники. В случае победы — премию, в случае провала — парашют.
Но на месте сотрудников стоило бы поинтересоваться: а зачем голову то вынимать? Чтобы прибыль у собственника повысить? Так пусть он и вынимает. По опыту премии получают не рядовые итшники, а большие начальники. В случае победы — премию, в случае провала — парашют.
А основная проблема бизнеса в том, что головы топ-менеджеров и собственников в заднице. И по сравнению с этим проблемы в ИТ — ничто.
На два экрана. Спасибо, что не на семь…
Достаточно было предпоследней строки. :)
Если конечно голову из задницы вынимает именно флакон а не перечисленные выше методики.
Достаточно было предпоследней строки. :)
Если конечно голову из задницы вынимает именно флакон а не перечисленные выше методики.
Все эти методики — часть флакона.
Разумеется, у них есть свои авторы, книжки, практика и т.д.
Но я лично каждую проверил, убедился в позитивном влиянии на эффективность и добавил во флакон.
Разумеется, у них есть свои авторы, книжки, практика и т.д.
Но я лично каждую проверил, убедился в позитивном влиянии на эффективность и добавил во флакон.
Вооот! Мы таки приближаемся к краткой формулировке которую я прошу.
Пока что она выглядит так:
Пока что она выглядит так:
Я, Иван Белокаменцев, начитал кучу разных методик для повышения личной эффективности и предприятия. Взяв лучше их них я создал свою: Флакон. Поверьте, что она работает лучше чем любая из составляющих ее. Я проверял.Но это не точно.
А если ставить программистам только правильные задачи в правильной последовательности, то счёт пойдёт на сотни процентов.
Jira на 1с. Забавно.
Я прошу прощения, а вы много джирой пользовались? Можно вам пару вопросов задать?
Я достаточно давно ее смотрел, хотел на ней работать — Flowcon, как методика, универсален, и может быть насажен на любой таск-менеджер.
Но не смог за время триала найти нужных возможностей, и бросил. Работал в Github Issues, там тоже неплохо, но не обойтись без программирования.
Вы знаете, как там построить какой-нибудь отчет или диаграмму по решенным задачам, чтобы показателем выступало числовое поле, которое я сам добавил?
Я достаточно давно ее смотрел, хотел на ней работать — Flowcon, как методика, универсален, и может быть насажен на любой таск-менеджер.
Но не смог за время триала найти нужных возможностей, и бросил. Работал в Github Issues, там тоже неплохо, но не обойтись без программирования.
Вы знаете, как там построить какой-нибудь отчет или диаграмму по решенным задачам, чтобы показателем выступало числовое поле, которое я сам добавил?
API — это прекрасно, но нафига мне тогда Jira, если не меньше половины кода надо писать заново? Ровно так же было с гитхабом — мучился несколько месяцев, пытаясь обойтись только предоставленным функционалом. Потом плюнул и написал себе пару отчетов на js через API. Еще несколько месяцев помучился. Открыл 1С, загрузил туда все задачи гитхаба и начал нормально обрабатывать данные. Но что тогда от гитхаба остается? Только морда? Нафига она мне? В случае с джирой — еще и деньги за нее платить.
Плюс, главное — это наши, программистские задачи могут жить в джире/гитхабе. А как быть тем, у кого задачи зависят от других данных? От заказов, оформленных в ERP? От оплат? От остатков товаров на складах? Им никогда никакая джира не поможет, увы. Ну или придется гигантскую сумму выложить за бэк, только для того, чтобы фронт был джировский.
Плюс, главное — это наши, программистские задачи могут жить в джире/гитхабе. А как быть тем, у кого задачи зависят от других данных? От заказов, оформленных в ERP? От оплат? От остатков товаров на складах? Им никогда никакая джира не поможет, увы. Ну или придется гигантскую сумму выложить за бэк, только для того, чтобы фронт был джировский.
У меня стратегия простая:
1. Там, где есть 1С, обычно никакой джиры нет. Ставишь 1Сный флакон сверху и наслаждаешься ростом эффективности;
2. Там, где есть джира или что-то подобное, пересаживаешься на облачный флакон. По своему опыту знаю, что пересесть с одного облачного решения на другое — несложно. Ну и наслаждаешься ростом эффективности.
3. А если есть и джира, и 1С, то получаешь двойной кайф, переходя на облако и ставя 1Сный флакон — они ж связаны друг с другом.
1. Там, где есть 1С, обычно никакой джиры нет. Ставишь 1Сный флакон сверху и наслаждаешься ростом эффективности;
2. Там, где есть джира или что-то подобное, пересаживаешься на облачный флакон. По своему опыту знаю, что пересесть с одного облачного решения на другое — несложно. Ну и наслаждаешься ростом эффективности.
3. А если есть и джира, и 1С, то получаешь двойной кайф, переходя на облако и ставя 1Сный флакон — они ж связаны друг с другом.
Пользовался много. И продолжаю пользоваться. Но сходу ответа на ваш вопрос у меня нет, возможно потому, что передо мной такой вопрос никогда не вставал.
А так да, ответ «JQL и API». Уверен, что это гораздо интереснее, чем программирование на языке 1С.
А так да, ответ «JQL и API». Уверен, что это гораздо интереснее, чем программирование на языке 1С.
автор пишет лучше чем говорит) чувствуется отсутствие опыта именно в разговорном жанре. может есть новые выступления?
Эм, меня глючит, или автор создал багтрекер? Типа bugzilla, jira и иже с ними.
Исполнитель есть, даты перехода из состояния в состояние — есть, «принять в работу» — статус Assigned — есть, комментарии — есть, история — есть.
ПС: разделение задачи между исполнителями по % кажется отсутствует, но мне кажется это тоже решаемо.
ПС 2: ага, еще четкое время на выполнение задачи, на анализ задачи.
Думаю, если бы кто-то задумывал сделать багтрекер для похожих/одинаковых задач, сложность выполнения которых реально оценить с большой вероятностью, у него наверное получился бы Флакон.
Исполнитель есть, даты перехода из состояния в состояние — есть, «принять в работу» — статус Assigned — есть, комментарии — есть, история — есть.
ПС: разделение задачи между исполнителями по % кажется отсутствует, но мне кажется это тоже решаемо.
ПС 2: ага, еще четкое время на выполнение задачи, на анализ задачи.
Думаю, если бы кто-то задумывал сделать багтрекер для похожих/одинаковых задач, сложность выполнения которых реально оценить с большой вероятностью, у него наверное получился бы Флакон.
Нет, вас не глючит. Ну или у нас одинаковые глюки.
Но справедливости ради хочу сказать, что изобретать велосипеды это такая… черта ИТшников. И опять же справедливости ради — часто новые велосипеды оказываются действительно лучше старых.
Но справедливости ради хочу сказать, что изобретать велосипеды это такая… черта ИТшников. И опять же справедливости ради — часто новые велосипеды оказываются действительно лучше старых.
И я еще добавлю, что знакомый и любимый велосипед зачастую помогает достигать целей быстрее и дешевле, чем незнакомый, но теоретически лучший или более универсальный.
Время на изучение велосипеда и привыкание, а порой еще и настройку с помощью не всегда лучших, но почти всегда сторонних специалистов, отвлекает от основного процесса и проекта и увеличивает сроки и затраты.
Время на изучение велосипеда и привыкание, а порой еще и настройку с помощью не всегда лучших, но почти всегда сторонних специалистов, отвлекает от основного процесса и проекта и увеличивает сроки и затраты.
Техника не имеет значения. В статье есть отдельный абзац с главным предложением:
Ну и простой критерий:
1. Если ваш багтрекер повысил вашу эффективность, то он крут;
2. Если ваш багтрекер не повысил вашу эффективность, то это просто багтрекер.
Повышение эффективности – главное назначение Flowcon, и как методики, и как автоматизированной системы.
Ну и простой критерий:
1. Если ваш багтрекер повысил вашу эффективность, то он крут;
2. Если ваш багтрекер не повысил вашу эффективность, то это просто багтрекер.
Если у вас раньше не было баг-трекера, то неудивительно, что эффективность повысилась, методика тут ни при чем. Если был, но другой, значит работа отдела была организована неэффективно, трекер ни при чем. Если у кого-то работа организована нормально, от вашего трекера эффективность не повысится.
Багтрекеры у меня есть с тех пор, как я начал работать. Т.е. с 2005 года.
Но вообще, меня нет смысла убеждать. Я очень долго сомневался и думал так же, как вы написали.
Но время шло, методика применялась то на одной команде, то на другой, то со мной, то без меня, и всякий раз давала рост.
Но я ни в чем не пытаюсь вас убедить.
Но вообще, меня нет смысла убеждать. Я очень долго сомневался и думал так же, как вы написали.
Но время шло, методика применялась то на одной команде, то на другой, то со мной, то без меня, и всякий раз давала рост.
Но я ни в чем не пытаюсь вас убедить.
Судя по вашему описанию работы отдела программистов 1С, в этом ничего удивительного. Видимо там просто принято работать неэффективно — как получится, тяп-ляп и в продакшн, потом баги разребать, править рабочую базу вручную. Без контроля версий, без тестирования, без ТЗ, каждый сам по себе что-то делает в системе.
Конкретно по описанию в статье эта система отличается от Jira разве что более жестким контролем даты, к которой надо выполнить задачу. Цикл задачи (принять в работу/в работе/выполнена), лог изменений, проиритет, это все стандартный функционал любого трекера.
К отчетам тоже есть вопросы. Например, график отклонений от очереди. Раньше никто не контролировал, чтобы делать задачи по очереди, потом стали контролировать. Понятно, что график пошел вниз. Только как делали условных 20 задач, запланированных на неделю, за неделю, так и делают, просто в другом порядке.
Или про эффективность. Сначала была непонятная формула, потом освоились, научились считать по ней, и стали чуть побольше параметры ставить, так чтобы оставалось правдой. Результат именно такой — в каждой команде этот график увеличивается.
Дело не в том, что вас кто-то убеждает, а в том, что вы всех пытаетесь убедить, что открыли какие-то тайные механизмы. Вам почти в каждой статье с техническими деталями пишут что вы изобретаете велосипед. Вы писали, что вылезли из одной скорлупы, вылезьте уже из скорлупы 1С и поймите, что в других областях это или давно придумано, или не нужно. Что есть подходы к управлению программным кодом, чтобы не допускать бесконечное количество багов,
что где-то по веским причинам недопустимо править что-то на продакшене, что документация бывает нужна всем участникам процесса, и там действительно написаны нужные вещи. И много чего еще.
Конкретно по описанию в статье эта система отличается от Jira разве что более жестким контролем даты, к которой надо выполнить задачу. Цикл задачи (принять в работу/в работе/выполнена), лог изменений, проиритет, это все стандартный функционал любого трекера.
К отчетам тоже есть вопросы. Например, график отклонений от очереди. Раньше никто не контролировал, чтобы делать задачи по очереди, потом стали контролировать. Понятно, что график пошел вниз. Только как делали условных 20 задач, запланированных на неделю, за неделю, так и делают, просто в другом порядке.
Или про эффективность. Сначала была непонятная формула, потом освоились, научились считать по ней, и стали чуть побольше параметры ставить, так чтобы оставалось правдой. Результат именно такой — в каждой команде этот график увеличивается.
Дело не в том, что вас кто-то убеждает, а в том, что вы всех пытаетесь убедить, что открыли какие-то тайные механизмы. Вам почти в каждой статье с техническими деталями пишут что вы изобретаете велосипед. Вы писали, что вылезли из одной скорлупы, вылезьте уже из скорлупы 1С и поймите, что в других областях это или давно придумано, или не нужно. Что есть подходы к управлению программным кодом, чтобы не допускать бесконечное количество багов,
что где-то по веским причинам недопустимо править что-то на продакшене, что документация бывает нужна всем участникам процесса, и там действительно написаны нужные вещи. И много чего еще.
Да, чуть не забыл: методика работает и без багтрекера, я проверял. Эффект ниже, но работает.
Я вам кстати совет дам, как еще процентов 10 добавить. Надо делать задачи не по порядку, а группировать по расположению в коде или в разделе системы. Когда у человека открыты нужные файлы, развернута тестовая среда, написаны нужные запросы, то сделать задачу со связанным функционалом получится быстрее.
ИМХО, Это будет работать только тогда, когда программист занимается только программированием и не может составить свой пул задач.
Привели бы оценку рабочего времени программиста: на что он тратит своё время. Ведь это является итогом внедрения: Что было до, что после? За счет чего увеличилось количество выполненных задач, почему раньше выполнялось меньше. Вроде бы это у вас спрашивал Vantela.
Сделать это у вас, на сколько я вижу по скринам, не получится, ведь нужно типизировать задачи.
PS полно аналогичных продуктов, мы сидим на itsm365.ru, не сочтите за рекламу
Привели бы оценку рабочего времени программиста: на что он тратит своё время. Ведь это является итогом внедрения: Что было до, что после? За счет чего увеличилось количество выполненных задач, почему раньше выполнялось меньше. Вроде бы это у вас спрашивал Vantela.
Сделать это у вас, на сколько я вижу по скринам, не получится, ведь нужно типизировать задачи.
PS полно аналогичных продуктов, мы сидим на itsm365.ru, не сочтите за рекламу
Хорошая статья, не очень понимаю почему заминусовали. Почему-то многие комментарии касаются технической части (что это похоже на другие таск-трекеры), хотя в статье прямым текстом написано, что суть в методике, а не в реализации.
Вопрос такой возник. Что, если при начале выполнения задачи оказалось, что её нужно декомпозировать на несколько более мелких? Как в этом случае идёт рабочий процесс?
Я в своём «обычном» таск-трекере в этом случае делаю подзадачи, в основной задаче ставлю планируемый срок завершения всех дочерних, и потом с дочерними работаю как с самостоятельными задачами. Если так же делать в вашей методике, то что тогда происходит со всеми приоритетами и прочими атрибутами?
Вопрос такой возник. Что, если при начале выполнения задачи оказалось, что её нужно декомпозировать на несколько более мелких? Как в этом случае идёт рабочий процесс?
Я в своём «обычном» таск-трекере в этом случае делаю подзадачи, в основной задаче ставлю планируемый срок завершения всех дочерних, и потом с дочерними работаю как с самостоятельными задачами. Если так же делать в вашей методике, то что тогда происходит со всеми приоритетами и прочими атрибутами?
Иван, всё супер, но почему исполнитель не может вернуть задачу инициатору на доработку? Получается, система априори считает всех инициаторов задачи 100% компетентными и 100% профессиональными людьми, то есть они не только _знают_, как поставить задачу, в которой будет вся необходимая и достаточная для выполнения информация, но и _хотят_ поставить её правильно.
Если у вас в компании это всё так, то отлично, и это уже половина успеха. Но почти везде, где я работал, инициаторы часто вообще не заморачивались в правильности постановки задач. Если что не получалось — виноват был всегда исполнитель, «проблемы индейцев шерифа не е… т» (с). И получается исполнителю приходит задание с неполной информацией, время исполнения уже пошло, и исполнитель бегает каждые пару часов к инициатору и выпрашивает поскорее предоставить недостающую информацию. А потом в конце месяца результаты смотрит какой-нибудь топ, который на 4 ступени выше исполнителя, и ему вообще не досуг разбираться, что в каждом конкретном задании не хватало информации для выполнения. Он видит результат, что исполнители опоздали в 60% заданий, значит лишить всех премии, а одного вообще уволить для острастки.
Здесь в комментах разумно написал один хабровчанин: задания от отдела к отделу должны идти под контролем двух начальников соответствующих отделов. Чтобы в случае некорректной постановки задачи, или при постановке невыполнимых сроков, не исполнитель рамсил с инициатором, а начальник отдела с начальником отдела.
Если у вас в компании это всё так, то отлично, и это уже половина успеха. Но почти везде, где я работал, инициаторы часто вообще не заморачивались в правильности постановки задач. Если что не получалось — виноват был всегда исполнитель, «проблемы индейцев шерифа не е… т» (с). И получается исполнителю приходит задание с неполной информацией, время исполнения уже пошло, и исполнитель бегает каждые пару часов к инициатору и выпрашивает поскорее предоставить недостающую информацию. А потом в конце месяца результаты смотрит какой-нибудь топ, который на 4 ступени выше исполнителя, и ему вообще не досуг разбираться, что в каждом конкретном задании не хватало информации для выполнения. Он видит результат, что исполнители опоздали в 60% заданий, значит лишить всех премии, а одного вообще уволить для острастки.
Здесь в комментах разумно написал один хабровчанин: задания от отдела к отделу должны идти под контролем двух начальников соответствующих отделов. Чтобы в случае некорректной постановки задачи, или при постановке невыполнимых сроков, не исполнитель рамсил с инициатором, а начальник отдела с начальником отдела.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вы как хотите, а я сделал