Техника не имеет значения. В статье есть отдельный абзац с главным предложением:
Повышение эффективности – главное назначение Flowcon, и как методики, и как автоматизированной системы.
Ну и простой критерий:
1. Если ваш багтрекер повысил вашу эффективность, то он крут;
2. Если ваш багтрекер не повысил вашу эффективность, то это просто багтрекер.
Похоже на правду, но суть неверна.
Флакон — это просто кейс, решение для определенных бизнесов.
Интереснее, как собирался кейс — бизнес-программированием.
Все эти методики — часть флакона.
Разумеется, у них есть свои авторы, книжки, практика и т.д.
Но я лично каждую проверил, убедился в позитивном влиянии на эффективность и добавил во флакон.
Должна, или не должна, решает ЛПР, в зависимости от целей и стратегии бизнеса. Ситуаций разных много.
Вот простой пример — франчайзи 1С, отдел сопровождения, решает разовые задачи клиентов.
Поступает задача, ее кто-то оценивает в часах, договариваются с клиентом о конкретной стоимости.
Реальные трудозатраты, по факту, получаются выше — это статистические данные. Получается, человек тратит в месяц 168 часов, и производит, допустим, 100 оплачиваемых часов.
Садим на флакон, он начинает решать задачи быстрее, при сохранении того же уровня качества. Теперь он за 168 часов времени производит 168 оплачиваемых часов.
Доход вырос на 68 %, если я не ошибаюсь — и у компании, и у программиста. Постоянные затраты не подросли, доля переменных осталась прежней.
API — это прекрасно, но нафига мне тогда Jira, если не меньше половины кода надо писать заново? Ровно так же было с гитхабом — мучился несколько месяцев, пытаясь обойтись только предоставленным функционалом. Потом плюнул и написал себе пару отчетов на js через API. Еще несколько месяцев помучился. Открыл 1С, загрузил туда все задачи гитхаба и начал нормально обрабатывать данные. Но что тогда от гитхаба остается? Только морда? Нафига она мне? В случае с джирой — еще и деньги за нее платить.
Плюс, главное — это наши, программистские задачи могут жить в джире/гитхабе. А как быть тем, у кого задачи зависят от других данных? От заказов, оформленных в ERP? От оплат? От остатков товаров на складах? Им никогда никакая джира не поможет, увы. Ну или придется гигантскую сумму выложить за бэк, только для того, чтобы фронт был джировский.
На счастье, у меня есть под рукой готовый список — оглавление курса/книги, которую пишу по флакону. Это примерно половина того, что есть в методике — методы, подходы, кейсы и рекомендации.
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С? Как вывести их на новый уровень и создать лучшую команду?
А эффективность повышается за счет вытаскивания головы из задницы. Достаточно коротко? :)
не снизить косты, а выпуск увеличить при той же доле переменных и той же сумме постоянных затрат. Флакон — про то, как делать больше в единицу времени.
Я прошу прощения, а вы много джирой пользовались? Можно вам пару вопросов задать?
Я достаточно давно ее смотрел, хотел на ней работать — Flowcon, как методика, универсален, и может быть насажен на любой таск-менеджер.
Но не смог за время триала найти нужных возможностей, и бросил. Работал в Github Issues, там тоже неплохо, но не обойтись без программирования.
Вы знаете, как там построить какой-нибудь отчет или диаграмму по решенным задачам, чтобы показателем выступало числовое поле, которое я сам добавил?
Я о том же переживаю. Но тут палка о двух концах. Вокруг них полно конкурентов, с очень схожим бизнесом. Если конкуренты узнают, что можно, например, процентов на 40 за месяц приподняться, почти ничего не меняя, то конкурентное преимущество будет утрачено.
У одного из клиентов, тоже пересаживающихся на флакон, посчитана, но они строго-настрого запретили рассказывать какую-либо конкретику.
У нас самих флакон высвободил время — при том же уровне доходов от услуг мы реализовали несколько проектов по разработке (включая сам флакон). Проекты запустились недавно, поэтому доходы от них пока скромные.
Друзья, небольшое объявление.
Мне надоело писать серию «Корпоративный Ламанчский». Несмотря на то, что я запланировал еще кучу эпизодов, я не могу больше найти причины для продолжения.
Я писал его ровно потому, что он кому-то нравился. Сейчас, судя по рейтингу, нравиться перестал.
Поэтому займусь другими делами.
Ну и простой критерий:
1. Если ваш багтрекер повысил вашу эффективность, то он крут;
2. Если ваш багтрекер не повысил вашу эффективность, то это просто багтрекер.
Флакон — это просто кейс, решение для определенных бизнесов.
Интереснее, как собирался кейс — бизнес-программированием.
Разумеется, у них есть свои авторы, книжки, практика и т.д.
Но я лично каждую проверил, убедился в позитивном влиянии на эффективность и добавил во флакон.
Вот простой пример — франчайзи 1С, отдел сопровождения, решает разовые задачи клиентов.
Поступает задача, ее кто-то оценивает в часах, договариваются с клиентом о конкретной стоимости.
Реальные трудозатраты, по факту, получаются выше — это статистические данные. Получается, человек тратит в месяц 168 часов, и производит, допустим, 100 оплачиваемых часов.
Садим на флакон, он начинает решать задачи быстрее, при сохранении того же уровня качества. Теперь он за 168 часов времени производит 168 оплачиваемых часов.
Доход вырос на 68 %, если я не ошибаюсь — и у компании, и у программиста. Постоянные затраты не подросли, доля переменных осталась прежней.
Плюс, главное — это наши, программистские задачи могут жить в джире/гитхабе. А как быть тем, у кого задачи зависят от других данных? От заказов, оформленных в ERP? От оплат? От остатков товаров на складах? Им никогда никакая джира не поможет, увы. Ну или придется гигантскую сумму выложить за бэк, только для того, чтобы фронт был джировский.
Я даже еще раз там зарегистрировался, еще раз попробую что-то приличное сделать.
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С? Как вывести их на новый уровень и создать лучшую команду?
А эффективность повышается за счет вытаскивания головы из задницы. Достаточно коротко? :)
Это главная проблема на данный момент. Потом решится как-нибудь, сейчас никто не верит.
Я достаточно давно ее смотрел, хотел на ней работать — Flowcon, как методика, универсален, и может быть насажен на любой таск-менеджер.
Но не смог за время триала найти нужных возможностей, и бросил. Работал в Github Issues, там тоже неплохо, но не обойтись без программирования.
Вы знаете, как там построить какой-нибудь отчет или диаграмму по решенным задачам, чтобы показателем выступало числовое поле, которое я сам добавил?
У нас самих флакон высвободил время — при том же уровне доходов от услуг мы реализовали несколько проектов по разработке (включая сам флакон). Проекты запустились недавно, поэтому доходы от них пока скромные.
Да, всё забываю сказать: продолжения книги «Проще, чем кажется» в открытом доступе не будет.
Я её перепишу почти с нуля. Зря вообще начал выкладывать, это сильно испортило книгу.
Вернусь к 3-4 главе — той границе, где я ее писал и еще не выкладывал, остальное сотру и напишу заново.
Когда напишу, буду решать, что с ней делать.
Может, вернусь когда-нибудь.
Мне надоело писать серию «Корпоративный Ламанчский». Несмотря на то, что я запланировал еще кучу эпизодов, я не могу больше найти причины для продолжения.
Я писал его ровно потому, что он кому-то нравился. Сейчас, судя по рейтингу, нравиться перестал.
Поэтому займусь другими делами.