Статья для тех, кто ищет инструменты управления такие как CRM,ERP. Выбраны соответствующие хабы: Управление проектами*, Управление персоналом*, ERP-системы*, CRM-системы*, Блог компании OneBox. Какие претензии? Возможно, вам стоит просто читать другие хабы. С уважением к хабраюзерам, которым я также являюсь, и к вам лично.
Если вам по каким-то вашим субъективным ассоциациям наш конструктор бизнес-процессов кажется схожим с какой-то частью этой картинки, то оставайтесь при своем мнении. Спорить бессмысленно. Но лично я (кроме может быть стрелок)) больше ничего и близко похожего не вижу)
Все что вы описали — это даже не самая большая проблемы :)
Когда вы начинаете использовать ваш whois на production'e и более-менее средних нагрузках, то сразу вылазит проблема «как проверить 20 доменов за секунду».
Разные whois сервера позволяют параллельно принимать только 1-N запросов. Например, ua только 3 в один момент времени (свыше — баниться на несколько минут), и т.д.
Например, у вас куплено 5 конкурирующих лицензий.
Это означает, что в один момент времени в системе будет работать только 5 человек. 6й просто не сможет войти.
Это тянет на отдельную статью, постараюсь ответить в ближайшее время.
Основная идея:
1. те кто способны придумывать задачи, не способны качественно и стабильно их выполнять. Поэтому, это разные люди.
2. если поставить задачу «придумать 100 фишек за день», то это сначала кажется не реальным, но когда ситуация безвыходная, мозг придумывает решение и выдает 100 фишек. Потом при помощи SWOT отбираем нужные, расписываем в production «что и как надо сделать».
Самый хороший показатель — это когда баги не появляются, когда их почти нет.
Когда экосистема в команде разработчиков построена так, что даже тестировщики не нужны. Сами все находят, сами все правят, без пинков :)
По-моему, процент багов достаточно хороший показатель качества.
Если разработчик нашел свой баг, и устранил его сам, то это не засчитывается ему в «баг», это идет как «improve».
Разработчику выгодно править даже не свои баги, потому что баг ему не засчитывается, а фикс бага засчитывается. Поэтому да, он не сообщит, чтобы не влетело коллеге, а исправит сам. Всем хорошо, и нам особенно :)
Тестировщику тоже не выгодно преподносить баги как improve, потому что от этого страдают его KPI.
И у нас сейчас есть TIER 2 Support, я просто об этом не написал.
Отчасти я с вами согласен. Просто мы используем другой подход:
Мы четко разделяем production (производство) и research-development (придумывание нового). R&D придумывает фишки, описывает максимально подробно как их сделать, делает инструкции, а производство реализовывает задуманное.
У R&D тоже есть week-plan.
Супер-спеца лучше использовать не для «сделай все сам», а для «придумай и распиши последовательность действий для производства, но сам не делай».
Немножко другой пример:
«Сварить борщ» это не задача, это примерно 15 задач: нарезать картошку, нарезать лук, налить воды, поставить кастрюлю на огонь, и т.д.
И мы расписываем задачи настолько подробно, чтобы ошибиться было нельзя.
Чуть позже научили OneBox расписывать так задачи самостоятельно.
Когда вы начинаете использовать ваш whois на production'e и более-менее средних нагрузках, то сразу вылазит проблема «как проверить 20 доменов за секунду».
Разные whois сервера позволяют параллельно принимать только 1-N запросов. Например, ua только 3 в один момент времени (свыше — баниться на несколько минут), и т.д.
Спасибо
Это означает, что в один момент времени в системе будет работать только 5 человек. 6й просто не сможет войти.
300 USD разово за одну конкурирующую лицензию.
Support и обновления — 10% в год.
Основная идея:
1. те кто способны придумывать задачи, не способны качественно и стабильно их выполнять. Поэтому, это разные люди.
2. если поставить задачу «придумать 100 фишек за день», то это сначала кажется не реальным, но когда ситуация безвыходная, мозг придумывает решение и выдает 100 фишек. Потом при помощи SWOT отбираем нужные, расписываем в production «что и как надо сделать».
Чем больше критериев, тем тяжелее обмануть систему.
Когда экосистема в команде разработчиков построена так, что даже тестировщики не нужны. Сами все находят, сами все правят, без пинков :)
По-моему, процент багов достаточно хороший показатель качества.
Если разработчик нашел свой баг, и устранил его сам, то это не засчитывается ему в «баг», это идет как «improve».
Разработчику выгодно править даже не свои баги, потому что баг ему не засчитывается, а фикс бага засчитывается. Поэтому да, он не сообщит, чтобы не влетело коллеге, а исправит сам. Всем хорошо, и нам особенно :)
Тестировщику тоже не выгодно преподносить баги как improve, потому что от этого страдают его KPI.
И у нас сейчас есть TIER 2 Support, я просто об этом не написал.
Немножко другой пример:
«Сварить борщ» это не задача, это примерно 15 задач: нарезать картошку, нарезать лук, налить воды, поставить кастрюлю на огонь, и т.д.
И мы расписываем задачи настолько подробно, чтобы ошибиться было нельзя.
Чуть позже научили OneBox расписывать так задачи самостоятельно.