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