Я ж ничего не предлагаю. Эта статья описывает явление. Как и вся серия «Карьерные стероиды».
Вот цитата из вступления:
Да. На высшую истину и полное раскрытие темы не претендую, только личный опыт.
Отдельно обращусь к тем, кто считает, что «надо просто хорошо делать свое дело». Скажу так: Удачи! Это не ирония, а искреннее послание. Я честно завидую тем, кто умеет строить «чистую» карьеру, без применения стероидов. Я так не умею. Если научусь – поделюсь опытом.
Я разницу понимаю, но спорить об этом бессмысленно. Ну вот скажу я вам: когда я был самураем, меня не интересовало ничего, кроме служения. Вы же не поверите. Но и не проверите.
Собственно, так можно сказать про весь кодекс самураев. И про Конфуция, и про Библию, и про что угодно.
Вопрос только — зачем? Зачем делать XOR, если можно OR?
Багтрекеры у меня есть с тех пор, как я начал работать. Т.е. с 2005 года.
Но вообще, меня нет смысла убеждать. Я очень долго сомневался и думал так же, как вы написали.
Но время шло, методика применялась то на одной команде, то на другой, то со мной, то без меня, и всякий раз давала рост.
Но я ни в чем не пытаюсь вас убедить.
У меня стратегия простая:
1. Там, где есть 1С, обычно никакой джиры нет. Ставишь 1Сный флакон сверху и наслаждаешься ростом эффективности;
2. Там, где есть джира или что-то подобное, пересаживаешься на облачный флакон. По своему опыту знаю, что пересесть с одного облачного решения на другое — несложно. Ну и наслаждаешься ростом эффективности.
3. А если есть и джира, и 1С, то получаешь двойной кайф, переходя на облако и ставя 1Сный флакон — они ж связаны друг с другом.
Техника не имеет значения. В статье есть отдельный абзац с главным предложением:
Повышение эффективности – главное назначение 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 за месяц приподняться, почти ничего не меняя, то конкурентное преимущество будет утрачено.
Вот цитата из вступления:
Собственно, так можно сказать про весь кодекс самураев. И про Конфуция, и про Библию, и про что угодно.
Вопрос только — зачем? Зачем делать XOR, если можно OR?
а мои примеры — из древнего мира, что ли?
Но вообще, меня нет смысла убеждать. Я очень долго сомневался и думал так же, как вы написали.
Но время шло, методика применялась то на одной команде, то на другой, то со мной, то без меня, и всякий раз давала рост.
Но я ни в чем не пытаюсь вас убедить.
1. Там, где есть 1С, обычно никакой джиры нет. Ставишь 1Сный флакон сверху и наслаждаешься ростом эффективности;
2. Там, где есть джира или что-то подобное, пересаживаешься на облачный флакон. По своему опыту знаю, что пересесть с одного облачного решения на другое — несложно. Ну и наслаждаешься ростом эффективности.
3. А если есть и джира, и 1С, то получаешь двойной кайф, переходя на облако и ставя 1Сный флакон — они ж связаны друг с другом.
Ну и простой критерий:
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, там тоже неплохо, но не обойтись без программирования.
Вы знаете, как там построить какой-нибудь отчет или диаграмму по решенным задачам, чтобы показателем выступало числовое поле, которое я сам добавил?