Потом на другую конференцию съездил, еще раз рассказал. Опять навалились с вопросами, загорелись желанием что-то изменить.
Я отвечал — пф, в чем проблема-то? Вы же программисты, возьмите и сделайте! Добавьте измерение задач, правильную систему приоритетов, учет компетенций и т.д.
Но, как ни странно, почти никто не кинулся менять свою систему. Сейчас, занимаясь несколькими проектами по ускорению команд, я продолжаю удивляться — блин, в чем проблема-то? Я же обо всем написал, что и как надо делать. Например, в «1С, не болей». Но нет, сидят, ничего не делают, только говорят — хотим ускориться, хотим больше денег зарабатывать, хотим прогресса.
В общем, я расстроился и решил сам эту систему сделать. Получилось управление задачами Flowcon. Спешу похвастаться — может, это вас подтолкнет к изменению своей системы?
Управление задачами в Flowcon – это два в одном: конфигурация для платформы 1С и облачный сервис. Они могут работать как в паре, так и по отдельности. Конфигурация может, и должна ставиться на любую другую корпоративную информационную систему, используемую на предприятии. Потому что задачи в отрыве от данных намного менее эффективны.
Конфигурация растет, как снежный ком, в хорошем смысле. Чем дальше, тем она полезнее и функциональнее. Мы сами ее используем, и постоянно обогащаем новыми идеями – и своими, и пользователей.
Методика
Ключевое отличие управления задачами Flowcon в том, что это конфигурация, реализованная по методике. Это не очередное решение, в котором «вы сможете настроить свои бизнес-процессы».
Вы наверняка знаете простую истину: проблема в процессе, а не в его автоматизации.
Методику управления задачами и проектами, которая повышает эффективность работы, мы нарабатывали несколько лет. И на внутренней автоматизации, когда работали на заводах, и на разработке массовых продуктов, и на проектах внедрения для внешних заказчиков.
Эта методика и стала основой Flowcon, а конфигурация управления задачами просто автоматизирует ее применение.
Соответственно, хочу предостеречь тех, кто захочет повторить мой путь: если вам принципиально важно работать так, как вы привыкли, то подобные решения могут вам не подойти. Может, поэтому никто свою систему не дорабатывает?
Что-то, конечно, получится, может станет прозрачнее, или проще, или интереснее, но вы не получите главного – повышения эффективности.
Если ваша эффективность не растет, или вообще не измерена (оценка «да все нормально вроде» — не измерение), то проблема в процессе, в методике управления задачами. Какой тогда смысл брать или создавать очередное решение, подстраивать его под свои процессы, и получать тот же результат?
Поэтому будьте готовы к изменениям. Иначе вас ждет разочарование – эффективность не вырастет.
Повышение эффективности – главное назначение Flowcon, и как методики, и как автоматизированной системы.
Краткая история методики Flowcon
Краткая история методики Flowcon – не такая уж и краткая, потому что продолжалась более 10 лет. Но мы старались подсократить, как могли – вот статья.
Процесс
Процесс движения задачи очень простой, состоит из трех участников – инициатора, ответственного и исполнителя. По нашей практике, это самый распространенный случай.
Инициатор – тот, кто ставит задачу. Это может быть внутренний заказчик, вроде главбуха, или начальник, или человек может сам себе поставить задачу. Ответственный – это координатор, который распределяет задачи. Может быть руководитель подразделения, или тимлидер, или просто координатор – такие должности тоже встречаются.
Исполнитель – тот, кто непосредственно реализует то, что написано в задаче. Исполнителя выбирает ответственный.
Разумеется, все эти роли может выполнять один человек – я сам, в основном, так и делаю, т.к. использую флакон для себя. Чтобы не тратить много времени на выбор самого себя, мы приделали быстрые кнопки.
Жизненный цикл задачи
В методике Flowcon крайне важен жизненный цикл задачи. По каждой из них, в любой момент времени, должно быть понятно – кто и что должен сделать. Принять в работу, выполнить, проверить результат, назначить исполнителя и т.д.
Выглядит жизненный цикл так:
1. Инициатор создает задачу, указывает ответственного, пишет чего хочет;
2. У ответственного два варианта – принять задачу в работу, или отправить на доработку, если постановка не годится:
3. В любой момент, пока задача не прошла весь цикл, инициатор может ее отменить;
4. Если ответственный отправляет задачу на доработку, инициатор может или пойти ему навстречу, или отменить задачу:
5. Когда задача, наконец, принята в работу, надо назначить исполнителя – этим занимается ответственный;
6. У исполнителя вариантов не много – он может только выполнить задачу
7. Когда исполнитель закончил, задача улетает инициатору, у которого два разумных варианта действий:
8. Если результат устраивает инициатора, то жизненный цикл задачи завершается. Если же что-то не так, то задача возвращается исполнителю.
История смены статусов, то есть жизненный цикл задачи, сохраняется:
История нужна для того, чтобы оценивать потери времени на этапах согласований, и соотносить ее со временем выполнения в соответствующих отчетах.
Текущий статус задачи отображается как в форме документа:
Так и в форме списка всех задач:
Регулярный менеджмент
Принципиально задача может находиться в трех ипостасях:
1. Нужно чье-то решение;
2. Ее нужно выполнять;
3. Про нее нужно забыть.
Про выполнение поговорим дальше, а пока – про принятие решений. Прием в работу, назначение исполнителя, уточнение постановки, проверка результата, доработка – все это состояния, в которых кто-то должен принять какое-то решение.
Методика Flowcon говорит, что решения надо принимать, по возможности, быстро, потому что пока нет решения, задача зависает на соответствующем участке жизненного цикла.
Чтобы не мучить пользователей, мы разделили список задач на три принципиальных раздела: принять решение, выполнить и просто список всех задач.
На закладке «В работе» собираются все задачи, по которым надо принять решение текущему пользователю системы:
Прелесть в том, что не надо ничего искать. Зашел в форму списка задач и сразу увидел, где нужно твое решение. Все раскидал, и занялся исполнением. Нормальное состояние списка «Принять решение» — пустое.
Но флакон не было бы флаконом, если бы не контролировал принятие решений. На каждый вид решения есть норматив времени в настройках Flowcon:
Понятно, что в реальной жизни одним и тем же нормативом всех пользователей не опишешь – кто-то ведь реально не может принимать решение в течение часа? Поэтому есть возможность задавать индивидуальные цифры, в расширении пользователя:
Соответственно, в списке «Принять решение» отображается срок реагирования, чтобы человек не переживал:
Параметры задачи
Параметры задачи – это оценка в баллах, срочность/важность и срок выполнения:
Оценка задачи в баллах – это самое главное. В методике Flowcon этому посвящен целый раздел, поэтому повторяться не буду.
Ставить задаче срок, или нет, решает инициатор. У меня нет однозначной рекомендации на счет того, нужен задачам срок, или нет. Важно правильно понимать, что этот срок означает.
Единственное, что хочется отметить: какой-то срок все-таки должен быть, иначе система приоритетов (см. ниже) сделает так, что задача не решится никогда. Поэтому у нас в настройках есть две опции:
Разумный срок – это некий срок по умолчанию, который ставится всем задачам, если инициатор не указал точную дату. Флажок «Всегда ставить срок выполнения» — чисто интерфейсный, он взводит флажок «Нужно выполнить к сроку» в каждой новой задаче.
Срочность и важность – это приоритеты по матрице Эйзенхауэра. Понимая, что мнение у инициатора и ответственного может различаться, мы возможность расстановки приоритетов для каждого. Заполнять эти реквизиты не обязательно.
Система приоритетов
Система приоритетов – одна из важнейших частей флакона. В методике много написано о том, почему важно максимально убрать возможность выбора задачи для исполнителя – эффективность от этого только выиграет, а человек мучиться не будет.
Мы долго думали, как устроить систему приоритетов, и пришли к самому простому решению – суммированию отдельных оценок каждого фактора, влияющего на приоритет. Сейчас таких факторов пять (будет больше):
Вы просто ставите баллы приоритета каждому фактору, а система смотрит на задачу, и если фактор присутствует, добавляет их к общей цифре приоритета. Например, если вы выбрали только один фактор – срочность инициатора, и поставили ему 2 балла, то срочная задача будет иметь приоритет 2, а не срочная – 0.
Чуть подробнее скажу про статус буфера. Буфер – это длина отрезка времени от даты принятия задачи в работу до установленного срока исполнения. Например, пусть это будет 10 дней.
В любой момент времени мы находимся в какой-то точке этого отрезка. Прошел один день – значит, позади 10 % отрезка. Прошло три дня – 30 %, и т.д.
Соответственно, есть и обратная цифра – сколько времени осталось до срока. Если прошел один день, то осталось 90 %. Если прошло три дня, то осталось 70 %, и т.д. Это и есть статус буфера.
Ну а дальше все просто. Вы в настройке приоритетов ставите цифру, которая называется «Предел статуса буфера» — это сумма, добавляемая к приоритету, когда статус буфера равен нулю, т.е наступил срок выполнения задачи. А пока срок не пришел, эта цифра умножается длину пройденного участка времени.
Например, вы поставили оценку 10. Если прошло 30 % времени, то к приоритету добавится 3. Если задача только-только поставлена, то прибавится 0. Если времени совсем не осталось, то добавиться 10.
А если срок уже прошел, то добавится больше 10. Например, если прошло 150 % времени, то добавится 15. Таким образом, никакая задача не пропадет, и не затеряется.
Настройки приоритетов хранятся в справочнике «Настройки очередей». Раз это справочник, то понятно – настроек можно быть сколько угодно. Основная, работающая по умолчанию, указывается в настройках Flowcon. Для конкретного исполнителя можно переопределить, в расширении пользователя.
Главный смысл, который мы вкладывали в систему приоритетов – простота. И настройки, и использования. Систему приоритетов нужно настроить один раз, и надолго о ней забыть – она будет работать сама.
Если приоритеты по матрице Эйзенхауэра – статические, то по статусу буфера – динамические. Система не забудет, что время идет, и будет автоматически двигать задачи в очереди, чтобы не допустить просрочку.
Каждой задаче присваивается, и автоматически пересчитывается номер в очереди. Очередь привязана к текущему исполнителю, т.е. она у каждого своя.
Текущий номер в очереди и приоритет можно увидеть как в форме задачи:
Так и в списке задач к исполнению:
Список задач, разумеется, сортирован по номеру в очереди. Исполнитель должен просто брать их по порядку, и делать. А если не делает, то флакон об этом покажет.
Отчеты
Соблюдает исполнитель очередность, или нет, видно в отчете «График отклонений от очереди»:
Когда исполнитель закрывает задачу, как выполненную, система запоминает, на какой позиции в очереди она была. Ну и рисует на графике сумму отклонений за период. Отклонение – это разница между позицией в очереди на момент закрытия, и единицей.
Как видите, у нас в Окнософте с очередью большие проблемы. А когда перешли на флакон, и увидели, то схватились за голову и стали исправляться – график пошел вниз.
Второй отчет – «График эффективности». Это самый главный отчет, в котором будет видеy рост эффективности исполнителей. На графике выводится количество баллов выполненных задач, в привязке к периоду.
Например, вот что происходило с нашей эффективностью:
Отчетливо видно, когда мы ходили в отпуск – март и август, был провал в сумме баллов. Хотя, в целом, тренд положительный и очень впечатляющий.
Не менее важный отчет, необходимый, в первую очередь, координатору каждый день – это «Контроль исполнителей».
Этот отчет – все в одном окне. Не надо никого дергать, спрашивать, кто как работает, кто сколько сделал. Зашел, и посмотрел.
Что важно – исполнение задач поделено по периодам, чтобы избежать влияния «вспышек» — например, если исполнитель закрыл сегодня одну большую задачу, а с начала месяца ничего не делал. Тут видно сразу и месяц, и неделю, и сегодняшний день. А подсветка красным поможет понять, у кого динамика нормальная, а у кого – трудности. Отличный повод поговорить.
Количество отчетов будет расти, пока – только те, без которых нельзя обойтись.
Мгновенные оценки
Важнейшим направлением развития системы являются мгновенные оценки. Раз мы знаем, с какой скоростью работают исполнители, как они соблюдают очередь, как укладываются в сроки, то мы можем делать прогнозы. Например, сколько реально времени займет выполнение задачи.
Функциональность мгновенных оценок еще не закончена, пока есть только один параметр – текущая скорость, т.е. сколько баллов задач человек выполняет в день.
Видно ее в форме выбора исполнителя:
Ответственный, зная оценку задачи, может сразу прикидывать, кому ее лучше поручить, исходя из текущей скорости.
Комментарии
Какая система управления задачами без прений? У нас тоже есть – комментарии.
Комментарии иерархические, поэтому видно, кто кому и на что отвечает. Ведется учет прочтения комментариев, поэтому в списке задач жирным выделяются те, где есть что почитать:
Сотрудничество
Методика флакон говорит, что люди должны сотрудничать. Часто бывает так, что один человек помогает другому решить задачу. Нам важно, чтобы вклад каждого был учтен, поэтому в задаче можно уточнить список исполнителей, и определить для каждого коэффициент трудового участия (КТУ):
Баллы за задачу будут поделены между исполнителями, в пропорции КТУ. Так, вроде, честнее.
Кстати, пока писал статью, весь мой список задач для принятия решения покраснел:
Пока, вроде, все.
Комментарии (61)
Paxest
27.02.2019 09:27+2одно странно выглядит: почему окно о выполнении задачи сразу летит от исполнителя инициатору над головой ответственного? Зачем нужен ответственный тогда? Работал с одной системой, где были только связи исполнитель- начальник отдела, тк отделов было много и работа пересекается со смежниками, то часто надо было выдавать задания в другой отдел. для этого нужно было получить под заданием подпись руководителя своего отдела и отдать её начальнику другого отдела. Дальше если начальник соглашался с заданием, то отдавал задание исполнителю в своём отделе. Копии делались всем участникам и всем начальникам. Дальше исполнители сами между собой договаривались о работе но только о том, что было написано в задании. Оценкой работы всех отделов служила вовремя выполненная работа. Все работали на общий результат, а не на баллы как у вас предложено. Потом эту систему с человеческим взаимодействием между разными отделами заменили электронной версией с кучей надстроек из-за чего теплые отношения ушли а остались вымученные поля в программе. Уже давно там не работаю, но система утверждения всего в два шага, с пониманием всех сторон о чем речь, до сих пор кажется идеальной. Простой, но эффективной. С прокачкой софтскилс при выдаче заданий. С общением между отделами. Мне кажется поэтому люди не делают системы
kagarich
27.02.2019 11:20Конкретно по флакону — кто-то из его разработчиков или внедренцев считал cost rate driver?
Какая экономическая выгода от этой системы, выраженная в рублях, долларах, иной валюте?
nmivan Автор
27.02.2019 11:58+1У одного из клиентов, тоже пересаживающихся на флакон, посчитана, но они строго-настрого запретили рассказывать какую-либо конкретику.
У нас самих флакон высвободил время — при том же уровне доходов от услуг мы реализовали несколько проектов по разработке (включая сам флакон). Проекты запустились недавно, поэтому доходы от них пока скромные.kagarich
27.02.2019 12:11+1но они строго-настрого запретили рассказывать какую-либо конкретику.
Ну а как так? Это главный мотив для внедрения подобного рода систем. До тех пор пока владельцу «на пальцах» нельзя будет обьяснить, что внедрение такой системы позволит сэкономить N рублей, и покажет как именно это будет сделано.nmivan Автор
27.02.2019 12:18Я о том же переживаю. Но тут палка о двух концах. Вокруг них полно конкурентов, с очень схожим бизнесом. Если конкуренты узнают, что можно, например, процентов на 40 за месяц приподняться, почти ничего не меняя, то конкурентное преимущество будет утрачено.
kagarich
27.02.2019 12:34Я правильно прочитал, что клиент после внедрения флакона смог снизить косты на 40%?
Если кратко, то ахренеть и слабо верю.
Если длинно, то я тут же бежал бы с флаконом к конкурентам «смотрите, я вам такую штуку поставлю, закачаетесь, ваши расходы минимум на 20% упадут, а у одного из ваших конкуртентов (не скажу у которого) вообще на 40% упали, хотите? вот здесь подпишите...»nmivan Автор
27.02.2019 12:48не снизить косты, а выпуск увеличить при той же доле переменных и той же сумме постоянных затрат. Флакон — про то, как делать больше в единицу времени.
kagarich
27.02.2019 13:07Опять не понимаю:
Все производственные сектора имеют друг на друга завязанную производительность. Ту главное, что каждый зависит от каждого: пока склад не оприходует сырье — оно не пойдет на производство (и количество принятого сырья зависит не столько от его размера, сколько от потребности рынка, то есть способности продать); пока производство не сделает продукт по определенной техкарте и со вполне очевидной производительностью — оно не уйдет на ОТК; пока ОТК не проверит, по вполне очевидной техкарте, с прогнозируемым % брака, продукт не уйдет на склад готовой продукции.
Я тут простейший процесс описал, и не понимаю — как флакон может повлиять на конечную производительность конкретного станка и оператора за ним? Или на производительность инженера по качеству?nmivan Автор
27.02.2019 13:33я говорил о выпуске продукции программистами.
kagarich
27.02.2019 13:47+1А разработка точно должна на 40% быстрее фигачить?
Т.е. какой потребности отвечает цель получить от разработчика на 40% быстрее результат? И всегда-ли «быстро» означает «качественно»?
Иван, я второй раз при прочтении ваших комментариев вспоминаю два анекдота, первый про "… но есть нюанс" я здесь приводить не буду, а вот второй под спойлером.
Заголовок спойлераСтоят на пригорке два быка, молодой и старый, и смотрят на пасущееся внизу в долине стадо коров. Молодой бычок, горячий, нетерпеливый, волнуется, рогом землю роет и обращается к старику: «Бык, а бык, давай быстренько спустимся вниз и поимеем в-о-н… ту рыженькую
коровку!!!
Старый отвечает медленно: „Нет! Мы этого делать не будем!“
Молодой успокаивается, но потом опять: » Бык, а бык, давай тогда быстренько спустимся вниз и поимеем вон ту черненькую…
В ответ звучит: «Нет! Мы этого делать не будем.»
Молодой (обиженно): " Ну что же мы тогда будем делать?"
Старый говорит с расстановкой: «Мы медленно спустимся вниз и поимеем все стадо»gennayo
27.02.2019 13:53Сейчас у приличных 1С франчей проблема — количество заказов превышает возможности имеющихся сотрудников, а новых сотрудников найти тяжело. Поэтому, преимущества ускорения на 40% для них очевидны.
nmivan Автор
27.02.2019 13:56+1Должна, или не должна, решает ЛПР, в зависимости от целей и стратегии бизнеса. Ситуаций разных много.
Вот простой пример — франчайзи 1С, отдел сопровождения, решает разовые задачи клиентов.
Поступает задача, ее кто-то оценивает в часах, договариваются с клиентом о конкретной стоимости.
Реальные трудозатраты, по факту, получаются выше — это статистические данные. Получается, человек тратит в месяц 168 часов, и производит, допустим, 100 оплачиваемых часов.
Садим на флакон, он начинает решать задачи быстрее, при сохранении того же уровня качества. Теперь он за 168 часов времени производит 168 оплачиваемых часов.
Доход вырос на 68 %, если я не ошибаюсь — и у компании, и у программиста. Постоянные затраты не подросли, доля переменных осталась прежней.
nmivan Автор
27.02.2019 12:49Если кратко, то ахренеть и слабо верю
Это главная проблема на данный момент. Потом решится как-нибудь, сейчас никто не верит.gennayo
27.02.2019 12:55+1Так не верят ИТ-шники на слово, им расчёты подавай — что было до, что изменилось, что стало после.
Vantela
27.02.2019 12:58+1И обоснование еще требуется.
Из воздуха получается только… воздух.gennayo
27.02.2019 13:07Какое ещё обоснование нужно, если расчёты покажут реальное улучшение целевых показателей на 40%, например?
kagarich
27.02.2019 13:09+2— Я те как брат брату говорю — точняк тема, минимум на 40% твои эти… целевые показатели… улучшатся.
— Гражданин, перестаньте меня обнимать, присаживайтесь пожалуйста. А теперь расскажите, что именно подразумеваются под «целевыми показателями» и, главное, термином «улучшатся». Зиночка, еще кофе пожалуйста…
Vantela
27.02.2019 12:57Потом могут и другие проблемы появиться.
Например, люди будут разбегаться из-за перенапряжения.
Кратковременно можно заставить человека выложиться на 200% и даже на 300%. А если он раньше ни черта не делал, то даже на 1000%. Но устойчивым показателем я бы это не назвал.nmivan Автор
27.02.2019 13:00Перенапряжения нет. Я на этой методике уже года три сижу. Эффективность растет, а работаю все меньше (по времени).
Vantela
27.02.2019 13:14+2Чудес не бывает.
Эффективность должна откуда то браться.
Варианты:
— раньше эффективность была близка в 0.
— эффективность всех работников близка к 0, а флакон каким то удивительным образом это исправляет — вот нужно понимание каким!
-лично Вы очень и очень выносливый человек
итд
У меня вот нет понимания каким образом эта методика может увеличивать эффективность без перенапряжения.
То что средний Итшник работает на работе значительно меньше положенных 8 часов для меня не новость. Если флакон заставляет работать 8 часов — это один из вариантов повышения эффективности. И фактор будущего выгорания.
Очень много людей имеют обыкновение «откладывать на потом» и таким образом терять задачи. Флакон может выступать в роли дятла и заставлять «ставить эту долбаную галочку сейчас, а не через пол года» — это тоже положительно сказывается на эффективности работы коллектива в первую очередь и личной тоже.
Иван, попробуйте сформулировать за счет чего Флакон повышает эффективность. Но не как вы любите — на 7 экранов. А кратко по пунктам без воды.nmivan Автор
27.02.2019 13:27На счастье, у меня есть под рукой готовый список — оглавление курса/книги, которую пишу по флакону. Это примерно половина того, что есть в методике — методы, подходы, кейсы и рекомендации.
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С? Как вывести их на новый уровень и создать лучшую команду?
А эффективность повышается за счет вытаскивания головы из задницы. Достаточно коротко? :)kagarich
27.02.2019 13:29А эффективность повышается за счет вытаскивания головы из задницы.
Другими словами, если голова полностью в заднице, то флакон позволит вытащить ее оттуда на 40%.
… но это не точно. Станет понятно, когда внедрим.RomanQA
27.02.2019 14:24ИМО это очень важно — чтобы сотрудники вытащили головы из задниц и начали наконец эффективно работать. Головы в заднице — одна из основных проблем в айти
Vantela
27.02.2019 14:27+1Если бы только в ИТ…
Но на месте сотрудников стоило бы поинтересоваться: а зачем голову то вынимать? Чтобы прибыль у собственника повысить? Так пусть он и вынимает. По опыту премии получают не рядовые итшники, а большие начальники. В случае победы — премию, в случае провала — парашют.
gennayo
27.02.2019 14:34А основная проблема бизнеса в том, что головы топ-менеджеров и собственников в заднице. И по сравнению с этим проблемы в ИТ — ничто.
Vantela
27.02.2019 14:36Это можно переформулировать:)
ТОП-менагеры думают о том какой островок в Тихом Океане купить… И куда вложить наличные миллионы.
А вы тут со своими головами… задницами…
Vantela
27.02.2019 14:24+1На два экрана. Спасибо, что не на семь…
Достаточно было предпоследней строки. :)
Если конечно голову из задницы вынимает именно флакон а не перечисленные выше методики.nmivan Автор
27.02.2019 14:26Все эти методики — часть флакона.
Разумеется, у них есть свои авторы, книжки, практика и т.д.
Но я лично каждую проверил, убедился в позитивном влиянии на эффективность и добавил во флакон.Vantela
27.02.2019 14:31Вооот! Мы таки приближаемся к краткой формулировке которую я прошу.
Пока что она выглядит так:
Я, Иван Белокаменцев, начитал кучу разных методик для повышения личной эффективности и предприятия. Взяв лучше их них я создал свою: Флакон. Поверьте, что она работает лучше чем любая из составляющих ее. Я проверял.
Но это не точно.nmivan Автор
27.02.2019 14:48Похоже на правду, но суть неверна.
Флакон — это просто кейс, решение для определенных бизнесов.
Интереснее, как собирался кейс — бизнес-программированием.
AlexLeonov
27.02.2019 11:54+2Jira на 1с. Забавно.
nmivan Автор
27.02.2019 12:20Я прошу прощения, а вы много джирой пользовались? Можно вам пару вопросов задать?
Я достаточно давно ее смотрел, хотел на ней работать — Flowcon, как методика, универсален, и может быть насажен на любой таск-менеджер.
Но не смог за время триала найти нужных возможностей, и бросил. Работал в Github Issues, там тоже неплохо, но не обойтись без программирования.
Вы знаете, как там построить какой-нибудь отчет или диаграмму по решенным задачам, чтобы показателем выступало числовое поле, которое я сам добавил?zharikovpro
27.02.2019 13:14Фишка в том, что у Jira есть API. И еще можно делать для нее плагины. И еще она в целом много фичей дает из коробки, и вообще лидер индустрии. Так что если сделать надстройку над ней, решение будет сразу будет намного солиднее выглядет (многим это важно) и будет более future-proof, так сказать. Облачную джиру опять-таки удобнее распространять. Подумайте, может таким образом распространять ваши идеи легче будет?
nmivan Автор
27.02.2019 13:32API — это прекрасно, но нафига мне тогда Jira, если не меньше половины кода надо писать заново? Ровно так же было с гитхабом — мучился несколько месяцев, пытаясь обойтись только предоставленным функционалом. Потом плюнул и написал себе пару отчетов на js через API. Еще несколько месяцев помучился. Открыл 1С, загрузил туда все задачи гитхаба и начал нормально обрабатывать данные. Но что тогда от гитхаба остается? Только морда? Нафига она мне? В случае с джирой — еще и деньги за нее платить.
Плюс, главное — это наши, программистские задачи могут жить в джире/гитхабе. А как быть тем, у кого задачи зависят от других данных? От заказов, оформленных в ERP? От оплат? От остатков товаров на складах? Им никогда никакая джира не поможет, увы. Ну или придется гигантскую сумму выложить за бэк, только для того, чтобы фронт был джировский.zharikovpro
27.02.2019 15:19> нафига мне тогда Jira, если не меньше половины кода надо писать заново
Как ледокол при принятии решений о внедрении методики в тех компаниях, где не используют 1С. Там где 1С уже есть — конечно же, Jira притягивать за уши не нужно.
> А как быть тем, у кого задачи зависят от других данных? От заказов, оформленных в ERP? От оплат? От остатков товаров на складах?
В таком случае и FlowCon не поможет, и обычно делают свой софт для поддержки БП, насколько я в курсе.nmivan Автор
27.02.2019 15:24У меня стратегия простая:
1. Там, где есть 1С, обычно никакой джиры нет. Ставишь 1Сный флакон сверху и наслаждаешься ростом эффективности;
2. Там, где есть джира или что-то подобное, пересаживаешься на облачный флакон. По своему опыту знаю, что пересесть с одного облачного решения на другое — несложно. Ну и наслаждаешься ростом эффективности.
3. А если есть и джира, и 1С, то получаешь двойной кайф, переходя на облако и ставя 1Сный флакон — они ж связаны друг с другом.zharikovpro
27.02.2019 21:22Хм, я забыл про пункт 2 с учетом облачной версии. Рабочий вариант, точно. Хотя и менее приятный, чем «была джира, осталась джира».
zharikovpro
27.02.2019 13:16> Вы знаете, как там построить какой-нибудь отчет или диаграмму по решенным задачам, чтобы показателем выступало числовое поле, которое я сам добавил?
Быстрое гугление подсказывает как минимум варианты решений: стандартными средствами или с помощью плагинов для отчетности.nmivan Автор
27.02.2019 13:28Гугление у меня тоже есть. Думал, вы по своему опыту подскажете.
Я даже еще раз там зарегистрировался, еще раз попробую что-то приличное сделать.
AlexLeonov
27.02.2019 15:28Пользовался много. И продолжаю пользоваться. Но сходу ответа на ваш вопрос у меня нет, возможно потому, что передо мной такой вопрос никогда не вставал.
А так да, ответ «JQL и API». Уверен, что это гораздо интереснее, чем программирование на языке 1С.
prokuratdm
27.02.2019 11:55автор пишет лучше чем говорит) чувствуется отсутствие опыта именно в разговорном жанре. может есть новые выступления?
dimkss
27.02.2019 12:19+3Эм, меня глючит, или автор создал багтрекер? Типа bugzilla, jira и иже с ними.
Исполнитель есть, даты перехода из состояния в состояние — есть, «принять в работу» — статус Assigned — есть, комментарии — есть, история — есть.
ПС: разделение задачи между исполнителями по % кажется отсутствует, но мне кажется это тоже решаемо.
ПС 2: ага, еще четкое время на выполнение задачи, на анализ задачи.
Думаю, если бы кто-то задумывал сделать багтрекер для похожих/одинаковых задач, сложность выполнения которых реально оценить с большой вероятностью, у него наверное получился бы Флакон.Vantela
27.02.2019 14:34+1Нет, вас не глючит. Ну или у нас одинаковые глюки.
Но справедливости ради хочу сказать, что изобретать велосипеды это такая… черта ИТшников. И опять же справедливости ради — часто новые велосипеды оказываются действительно лучше старых.dzsysop
27.02.2019 18:22И я еще добавлю, что знакомый и любимый велосипед зачастую помогает достигать целей быстрее и дешевле, чем незнакомый, но теоретически лучший или более универсальный.
Время на изучение велосипеда и привыкание, а порой еще и настройку с помощью не всегда лучших, но почти всегда сторонних специалистов, отвлекает от основного процесса и проекта и увеличивает сроки и затраты.
nmivan Автор
27.02.2019 14:50Техника не имеет значения. В статье есть отдельный абзац с главным предложением:
Повышение эффективности – главное назначение Flowcon, и как методики, и как автоматизированной системы.
Ну и простой критерий:
1. Если ваш багтрекер повысил вашу эффективность, то он крут;
2. Если ваш багтрекер не повысил вашу эффективность, то это просто багтрекер.michael_vostrikov
27.02.2019 21:12+1Если у вас раньше не было баг-трекера, то неудивительно, что эффективность повысилась, методика тут ни при чем. Если был, но другой, значит работа отдела была организована неэффективно, трекер ни при чем. Если у кого-то работа организована нормально, от вашего трекера эффективность не повысится.
nmivan Автор
27.02.2019 21:25Багтрекеры у меня есть с тех пор, как я начал работать. Т.е. с 2005 года.
Но вообще, меня нет смысла убеждать. Я очень долго сомневался и думал так же, как вы написали.
Но время шло, методика применялась то на одной команде, то на другой, то со мной, то без меня, и всякий раз давала рост.
Но я ни в чем не пытаюсь вас убедить.michael_vostrikov
27.02.2019 23:01+1Судя по вашему описанию работы отдела программистов 1С, в этом ничего удивительного. Видимо там просто принято работать неэффективно — как получится, тяп-ляп и в продакшн, потом баги разребать, править рабочую базу вручную. Без контроля версий, без тестирования, без ТЗ, каждый сам по себе что-то делает в системе.
Конкретно по описанию в статье эта система отличается от Jira разве что более жестким контролем даты, к которой надо выполнить задачу. Цикл задачи (принять в работу/в работе/выполнена), лог изменений, проиритет, это все стандартный функционал любого трекера.
К отчетам тоже есть вопросы. Например, график отклонений от очереди. Раньше никто не контролировал, чтобы делать задачи по очереди, потом стали контролировать. Понятно, что график пошел вниз. Только как делали условных 20 задач, запланированных на неделю, за неделю, так и делают, просто в другом порядке.
Или про эффективность. Сначала была непонятная формула, потом освоились, научились считать по ней, и стали чуть побольше параметры ставить, так чтобы оставалось правдой. Результат именно такой — в каждой команде этот график увеличивается.
Дело не в том, что вас кто-то убеждает, а в том, что вы всех пытаетесь убедить, что открыли какие-то тайные механизмы. Вам почти в каждой статье с техническими деталями пишут что вы изобретаете велосипед. Вы писали, что вылезли из одной скорлупы, вылезьте уже из скорлупы 1С и поймите, что в других областях это или давно придумано, или не нужно. Что есть подходы к управлению программным кодом, чтобы не допускать бесконечное количество багов,
что где-то по веским причинам недопустимо править что-то на продакшене, что документация бывает нужна всем участникам процесса, и там действительно написаны нужные вещи. И много чего еще.gennayo
28.02.2019 06:29На 1С, кстати, возможно и тестирование всех видов, и разработка по BDD, и CI/CD. И даже сам вендор всё это использует, местами.
nmivan Автор
27.02.2019 21:26Да, чуть не забыл: методика работает и без багтрекера, я проверял. Эффект ниже, но работает.
michael_vostrikov
27.02.2019 21:24Я вам кстати совет дам, как еще процентов 10 добавить. Надо делать задачи не по порядку, а группировать по расположению в коде или в разделе системы. Когда у человека открыты нужные файлы, развернута тестовая среда, написаны нужные запросы, то сделать задачу со связанным функционалом получится быстрее.
n0wheremany
27.02.2019 17:06+2ИМХО, Это будет работать только тогда, когда программист занимается только программированием и не может составить свой пул задач.
Привели бы оценку рабочего времени программиста: на что он тратит своё время. Ведь это является итогом внедрения: Что было до, что после? За счет чего увеличилось количество выполненных задач, почему раньше выполнялось меньше. Вроде бы это у вас спрашивал Vantela.
Сделать это у вас, на сколько я вижу по скринам, не получится, ведь нужно типизировать задачи.
PS полно аналогичных продуктов, мы сидим на itsm365.ru, не сочтите за рекламу
Aracon
28.02.2019 22:20+1Хорошая статья, не очень понимаю почему заминусовали. Почему-то многие комментарии касаются технической части (что это похоже на другие таск-трекеры), хотя в статье прямым текстом написано, что суть в методике, а не в реализации.
Вопрос такой возник. Что, если при начале выполнения задачи оказалось, что её нужно декомпозировать на несколько более мелких? Как в этом случае идёт рабочий процесс?
Я в своём «обычном» таск-трекере в этом случае делаю подзадачи, в основной задаче ставлю планируемый срок завершения всех дочерних, и потом с дочерними работаю как с самостоятельными задачами. Если так же делать в вашей методике, то что тогда происходит со всеми приоритетами и прочими атрибутами?nmivan Автор
28.02.2019 22:26Если новых задач много, или на их выполнение нужно много времени, то просто добавляются новые задачи.
Если задач немного, то просто увеличивается оценка.
sshmakov
Вот и молодец. Серьезно. Осталось только разруху в головах убрать, в виде нежелания прилагать усилия для изменений.