Люди добрые, у кого есть девайс проверьте на нем приложение silk-paints.com/
Оно было фичеред в самсунг сторе для галакси нота, т.е. рекомендовано для работы с SPen.
Будем рады любому фидбеку.
Есть ли какие-то фичи которые надо реализовать специально для реализации пера от Асуса в нашем приложении?
Какими еще приложениями для пера вы пользуетесь на вашем девайсе?
Ну вот смысл матрицы в том что она добавляет еще одно измерение.
Просто вверх или низ конечно же лучше чем просто хаос.
Но разброс по плоскости дает больше информации для принятия решения человеком.
Безусловно это нужно не всегда.
Надо отметить что в данном случае команда проекта построена по принципу схожему с принципами Тойоты (родоначальницы канбана) — все что можно аутсорсить надо аутсорсить.
Поэтому команда должна справляться с маршрутизацией задач и контролировать их исполнение.
Для этого все надо держать в голове и оперативно мониторить.
Т.е. команда и эта доска являются такми ЦУПом.
Например субподрядчики по приложению и по вебу могут схавать гораздо больший объем задач
Проблема в том что надо контролировать бюджет, и что особо важно выполнение некоторых задач не имеет смысла без выполнения задач в других потоках. И это можно видеть визуально.
Повторюсь.
На вас сваливается поток, который нельзя проигнорировать, его надо разгрести.
Новые задачи сыпятся десятками в день.
Их надо тут же маршрутизировать.
Я привел нашу ситуацию. Выход на рынок.
когда вы из двух человек должны стать в течении 2-3х месяцев как минимум командой из 10ти человек
их всех надо нанять потому что объем работы на каждую роль уже достаточный.
Надо параллельно искать людей и продолжать управлять продуктом.
т.к. поиск нужного человека не такое быстрое дело.
вот тут habrahabr.ru/post/120517/ хорошо показано
и стикеры можно прямо вот так по карте расположить
и брать в работу тот который максимально близко к правому верхнему углу находится
Фактически это одно и тоже. Просто такой способ визуализации.
Мы раньше пробовали визуализировать приоритет цветами, но это оказалось неудобно и все забили на это.
В частности на стикерах видно несколько колонок и одна из них как раз и есть приоритет из багтрекера.
Есть одно кардинальное отличие которое помогает решить матрица.
Вы можете оперативно и понятным образом переигрывать приоритеты.
Дело в том что в багтрекере обычно 4 уровня приоритета, а если у вас 40 задач и все Immediate?
И все надо сделать вчера.
Если хорошенько потрясти продукт овнера он вам все-таки скажет что некоторые задачи равнее других.
т.е. если оно срочное но неважное лучше его быстренько на кого-то делегировать.
Даже если сделают не так как надо, то потери небольшие.
Если оно важное но не срочное, то моно его в фоновом режиме делать самому. Не торопясь и сконцентрировавшись на срочных важных.
В нашем же посте мы говорим о том что в процесс работы должны уходить первыми те задачи которые срочные важные.
И если в какой-то фиче полно срочно важных, а в какой-то другой таковых не осталось, то если есть возможность вероятно надо перераспределить ресурсы. И самое ценное это видно с одного взгляда.
Про канбан я прекрасно знаю, и использовал его гораздо раньше чем это слово появилось на хабре. т.к. являюсь адептом, консультантом и со-основателем консалтинговой компании спецаилизирующейся на Lean. Agile я практикую уже лет 12.
Канбан изначально придуман там, где идет поставка однотипных изделий.
А когда перед вам стоит такой спектр задач который вы даже охватить не в состоянии разом. Когда майнд-мап проекта становится настолько тяжелым что по нему неудобно осуществлять навигацию и очевидно что надо разбивать на несколько отдельных карт и раздавать на разных ответственных лиц. Тогда вам надо разделять и классифицировать задачи.
Если вы внимательно читали, то я написал что на выходе из квадранта дальше зачастую и идет канбан.
Квадрант тут решает задачу выбора таска на подачу в прцесс исполнения.
А что именно? Это не я придумал.
По оси Y — Важность. Чтоб больше было понятно как мерить важность я оцениваю стоимость рисков или потерь в случае если задача не будет сделана.
По оси X — Срочность. Т.е. время после которого решение этой задачи уже не будет иметь значения.
Срочные неважные — задачи которые надо сделать срочно. например выставиться на какой-то ярмарке. Но они не очень важные для проекта т.к. там не очень большой профит ожидался.
Когда вы делаете проект на 10-15 тысяч человеко-часов
вы вынуждены распараллеливать работу
и начинать верстку не дожидаясь того когда «весь» функционал будет сделан
особенно если учесть что состояние «весь» не бывает вообще никогда достигнуто как минимум в половине проектов
хотя бы потому что в процессе работы даже если был подписан договор с макетами
все равно выясняется что что-то надо убрать, что-то переделать, а чегото срочно добавить причем раньше чем сдать основной функционал в договоре.
ну и опять же не уверен что 100% объективно «писать css» отделять от «верстать»
мы не имеем отдельной должность CSSщик
для нас это верстальщик
и это другой человек чем программер
с другими навыками и умениями.
>в плоть до версии 1.3 после обновления, на которую код, который был валидным в 1.2 вдруг стал не валидным.
Ну это нормально произошло ужесточение стандарта в следующей версии.
стандартизация идет шаг за шагом
мы в свое время вводили стандарты кодирования в крупном проекте там тоже все было более сурово с каждым нововведением.
Стандарты нужны и соблюдать и надо перманентно для того чтоб была высокая читаемость кода.
Сколько у вас людей работает одновременно над одним проектом?
Вот все у нас все делают в последний день :-)
Поэтому и очереди в налоговой :-)
Про размытие впечатлений — не аргумент вообще.
Никто такую кучу не будет сравнивать только по впечатлением.
Есть анкета 10 параметров.
два эксперта независимо проставляют баллы, считается среднее
В итоге получаются отсортированные проекты.
реально на впечатлении выбирают 8 из 16
А как Морейнис адекватно выбирает проекты?
Че тут жаловаться, танцует тот кто заказывает.
А что если они оценивали проекты по мере поступления.
И тогда в последний день им надо было оценить десяток последних проектов и сравнить с уже ранее отобранными из ранее оцененых?
Не знаю как сейчас, а года 4 назад мне в Доку вики не хватило много важных вещей для корпоративной вики.
Реализацию которых я нашел в ru.wikipedia.org/wiki/WackoWiki
Древовидная структура с разграничением доступа по веткам и наследованием прав (Для приватной документации разных подразделений).
Ну и управление правами не через конфиги а в понятном для руководителя подразделения веб-интерфейсе.
Ну и всякие штуки важные для корпоративного использования типа LDAP из коробки (с этого надо начинать).
Оно было фичеред в самсунг сторе для галакси нота, т.е. рекомендовано для работы с SPen.
Будем рады любому фидбеку.
Есть ли какие-то фичи которые надо реализовать специально для реализации пера от Асуса в нашем приложении?
Какими еще приложениями для пера вы пользуетесь на вашем девайсе?
Как инструмент решения СВОИХ задач.
никто не заставлял.
Более того если говорить про партнеров.
То, Вика 23 года, является партнером и владеет 10% в ООО стартапа.
Ну и таки да, запуск стартапа это военные действия.
Просто вверх или низ конечно же лучше чем просто хаос.
Но разброс по плоскости дает больше информации для принятия решения человеком.
Безусловно это нужно не всегда.
Поэтому команда должна справляться с маршрутизацией задач и контролировать их исполнение.
Для этого все надо держать в голове и оперативно мониторить.
Т.е. команда и эта доска являются такми ЦУПом.
Например субподрядчики по приложению и по вебу могут схавать гораздо больший объем задач
Проблема в том что надо контролировать бюджет, и что особо важно выполнение некоторых задач не имеет смысла без выполнения задач в других потоках. И это можно видеть визуально.
Повторюсь.
На вас сваливается поток, который нельзя проигнорировать, его надо разгрести.
Новые задачи сыпятся десятками в день.
Их надо тут же маршрутизировать.
когда вы из двух человек должны стать в течении 2-3х месяцев как минимум командой из 10ти человек
их всех надо нанять потому что объем работы на каждую роль уже достаточный.
Надо параллельно искать людей и продолжать управлять продуктом.
т.к. поиск нужного человека не такое быстрое дело.
и стикеры можно прямо вот так по карте расположить
и брать в работу тот который максимально близко к правому верхнему углу находится
Мы раньше пробовали визуализировать приоритет цветами, но это оказалось неудобно и все забили на это.
В частности на стикерах видно несколько колонок и одна из них как раз и есть приоритет из багтрекера.
Есть одно кардинальное отличие которое помогает решить матрица.
Вы можете оперативно и понятным образом переигрывать приоритеты.
Дело в том что в багтрекере обычно 4 уровня приоритета, а если у вас 40 задач и все Immediate?
И все надо сделать вчера.
Если хорошенько потрясти продукт овнера он вам все-таки скажет что некоторые задачи равнее других.
www.vkuzmin.com/2010/08/blog-post_13.html
Спокойно Сам
Мусор Зам
т.е. если оно срочное но неважное лучше его быстренько на кого-то делегировать.
Даже если сделают не так как надо, то потери небольшие.
Если оно важное но не срочное, то моно его в фоновом режиме делать самому. Не торопясь и сконцентрировавшись на срочных важных.
В нашем же посте мы говорим о том что в процесс работы должны уходить первыми те задачи которые срочные важные.
И если в какой-то фиче полно срочно важных, а в какой-то другой таковых не осталось, то если есть возможность вероятно надо перераспределить ресурсы. И самое ценное это видно с одного взгляда.
Мне показалось что будет визуальный шум.
Канбан изначально придуман там, где идет поставка однотипных изделий.
А когда перед вам стоит такой спектр задач который вы даже охватить не в состоянии разом. Когда майнд-мап проекта становится настолько тяжелым что по нему неудобно осуществлять навигацию и очевидно что надо разбивать на несколько отдельных карт и раздавать на разных ответственных лиц. Тогда вам надо разделять и классифицировать задачи.
Если вы внимательно читали, то я написал что на выходе из квадранта дальше зачастую и идет канбан.
Квадрант тут решает задачу выбора таска на подачу в прцесс исполнения.
По оси Y — Важность. Чтоб больше было понятно как мерить важность я оцениваю стоимость рисков или потерь в случае если задача не будет сделана.
По оси X — Срочность. Т.е. время после которого решение этой задачи уже не будет иметь значения.
Срочные неважные — задачи которые надо сделать срочно. например выставиться на какой-то ярмарке. Но они не очень важные для проекта т.к. там не очень большой профит ожидался.
вы вынуждены распараллеливать работу
и начинать верстку не дожидаясь того когда «весь» функционал будет сделан
особенно если учесть что состояние «весь» не бывает вообще никогда достигнуто как минимум в половине проектов
хотя бы потому что в процессе работы даже если был подписан договор с макетами
все равно выясняется что что-то надо убрать, что-то переделать, а чегото срочно добавить причем раньше чем сдать основной функционал в договоре.
ну и опять же не уверен что 100% объективно «писать css» отделять от «верстать»
мы не имеем отдельной должность CSSщик
для нас это верстальщик
и это другой человек чем программер
с другими навыками и умениями.
Ну это нормально произошло ужесточение стандарта в следующей версии.
стандартизация идет шаг за шагом
мы в свое время вводили стандарты кодирования в крупном проекте там тоже все было более сурово с каждым нововведением.
Стандарты нужны и соблюдать и надо перманентно для того чтоб была высокая читаемость кода.
Сколько у вас людей работает одновременно над одним проектом?
Поэтому и очереди в налоговой :-)
Про размытие впечатлений — не аргумент вообще.
Никто такую кучу не будет сравнивать только по впечатлением.
Есть анкета 10 параметров.
два эксперта независимо проставляют баллы, считается среднее
В итоге получаются отсортированные проекты.
реально на впечатлении выбирают 8 из 16
А как Морейнис адекватно выбирает проекты?
Че тут жаловаться, танцует тот кто заказывает.
И тогда в последний день им надо было оценить десяток последних проектов и сравнить с уже ранее отобранными из ранее оцененых?
FIFO с накопителем так сказать.
Реализацию которых я нашел в ru.wikipedia.org/wiki/WackoWiki
Древовидная структура с разграничением доступа по веткам и наследованием прав (Для приватной документации разных подразделений).
Ну и управление правами не через конфиги а в понятном для руководителя подразделения веб-интерфейсе.
Ну и всякие штуки важные для корпоративного использования типа LDAP из коробки (с этого надо начинать).