Comments 15
Для типовых проектов и следовательно типовых же задач описанная вами схема может и подойдет. Но если надо делать уникальные проекты, то ничего другого, кроме как найма супер-спецов с большим опытом разработки, достаточным для прогнозирования сроков/затрат на уникальную разработку пока еще никто не придумал. И да, это будет уже не серийное производство, а творчество. И кстати нигде в древних текстах не указано, что Творец Всего делал эстимейт на создание нашего мира. Просто поработал как следует достаточное количество времени над очередным проектом, посмотрел на то что у него получилось, и сказал Он что это хорошо!
Отчасти я с вами согласен. Просто мы используем другой подход:
Немножко другой пример:
«Сварить борщ» это не задача, это примерно 15 задач: нарезать картошку, нарезать лук, налить воды, поставить кастрюлю на огонь, и т.д.
И мы расписываем задачи настолько подробно, чтобы ошибиться было нельзя.
Чуть позже научили OneBox расписывать так задачи самостоятельно.
- Мы четко разделяем production (производство) и research-development (придумывание нового). R&D придумывает фишки, описывает максимально подробно как их сделать, делает инструкции, а производство реализовывает задуманное.
- У R&D тоже есть week-plan.
- Супер-спеца лучше использовать не для «сделай все сам», а для «придумай и распиши последовательность действий для производства, но сам не делай».
Немножко другой пример:
«Сварить борщ» это не задача, это примерно 15 задач: нарезать картошку, нарезать лук, налить воды, поставить кастрюлю на огонь, и т.д.
И мы расписываем задачи настолько подробно, чтобы ошибиться было нельзя.
Чуть позже научили OneBox расписывать так задачи самостоятельно.
Привет,
я ранее работал в отделе Tier 3 Support (поддержка третьей линии, куда прилетают самые сложные баги). Внесу свои пять копеек.
История про процент багов выглядит очень неправдоподобно. Этот критерий надо убирать как можно скорее.
Очень подозреваю, что разработчики договорились с тестировщиками и что-то заметается под ковёр, чтобы процент был хорошим. И это потом аукнется через год-другой как огромный технический долг.
Процент багов разработчик может уменьшить, «если сильно захочет», только если высокий процент ранее объяснялся регулярным пренебрежением тестированием и т.п. Все остальные баги уменьшить мотивацией невозможно.
Ещё проблема — допустим, баг нашёл не тестировщик, а разработчик (реализовывал какую-то фичу и заметил ошибку в коде) — думаете, он сообщит о таком баге, зная, что за это влетит его коллеге за соседним столом?
В качестве альтернативы могу предложить иметь подотдел именно что Tier 3 Support — программистов, ответственных за устранение технического долга (не только багов), которые будут только чинить баги. Это решит проблему «если баг — это задача, то [...]».
я ранее работал в отделе Tier 3 Support (поддержка третьей линии, куда прилетают самые сложные баги). Внесу свои пять копеек.
История про процент багов выглядит очень неправдоподобно. Этот критерий надо убирать как можно скорее.
Очень подозреваю, что разработчики договорились с тестировщиками и что-то заметается под ковёр, чтобы процент был хорошим. И это потом аукнется через год-другой как огромный технический долг.
Процент багов разработчик может уменьшить, «если сильно захочет», только если высокий процент ранее объяснялся регулярным пренебрежением тестированием и т.п. Все остальные баги уменьшить мотивацией невозможно.
Ещё проблема — допустим, баг нашёл не тестировщик, а разработчик (реализовывал какую-то фичу и заметил ошибку в коде) — думаете, он сообщит о таком баге, зная, что за это влетит его коллеге за соседним столом?
В качестве альтернативы могу предложить иметь подотдел именно что Tier 3 Support — программистов, ответственных за устранение технического долга (не только багов), которые будут только чинить баги. Это решит проблему «если баг — это задача, то [...]».
Спасибо за комментарий.
По-моему, процент багов достаточно хороший показатель качества.
Если разработчик нашел свой баг, и устранил его сам, то это не засчитывается ему в «баг», это идет как «improve».
Разработчику выгодно править даже не свои баги, потому что баг ему не засчитывается, а фикс бага засчитывается. Поэтому да, он не сообщит, чтобы не влетело коллеге, а исправит сам. Всем хорошо, и нам особенно :)
Тестировщику тоже не выгодно преподносить баги как improve, потому что от этого страдают его KPI.
И у нас сейчас есть TIER 2 Support, я просто об этом не написал.
По-моему, процент багов достаточно хороший показатель качества.
Если разработчик нашел свой баг, и устранил его сам, то это не засчитывается ему в «баг», это идет как «improve».
Разработчику выгодно править даже не свои баги, потому что баг ему не засчитывается, а фикс бага засчитывается. Поэтому да, он не сообщит, чтобы не влетело коллеге, а исправит сам. Всем хорошо, и нам особенно :)
Тестировщику тоже не выгодно преподносить баги как improve, потому что от этого страдают его KPI.
И у нас сейчас есть TIER 2 Support, я просто об этом не написал.
Ещё проблема с багами — какие-то баги есть всегда, а в вашей схеме если баги нашлись, то это плохо.
А плохо-то наоборот когда они не нашлись.
А плохо-то наоборот когда они не нашлись.
Пожалуй, одна из лучших публикаций о распределении ролей в процессе организации бизнеса.
Разработчик (рабочий) не должен ставить себя во главе угла, так как страдают все: заказчики (ждущие ненормированное количество времени своего заказа), менеджеры (которые не знают, когда будет готовый результат, а могут примерно угадывать) и вся бизнес-система в целом (уменьшение лояльности клиентов и менеджеров).
Но тут главное не переборщить и не бороться за каждую сэкономленную секунду.
Разработчик (рабочий) не должен ставить себя во главе угла, так как страдают все: заказчики (ждущие ненормированное количество времени своего заказа), менеджеры (которые не знают, когда будет готовый результат, а могут примерно угадывать) и вся бизнес-система в целом (уменьшение лояльности клиентов и менеджеров).
Но тут главное не переборщить и не бороться за каждую сэкономленную секунду.
Проблема в том, что с введением формальных критериев качества люди устремляются достигать не результата, а выполнения именно этих формальных критериев. Хорошо об этом написано вот тут
Тут скорее речь не о разработчиках, а о кодерах, машинах исполнения задач. Автор в статье, на самом деле, это и признаёт. В результате вероятность вот такого – высокая: «Как программист я понимаю, что надо было сделать ещё это и это, но поставлено этого мне не было, потому и не сделано. Ты менеджер, ты и решай». Даже у водителя мусоровоза пространство решений оказывается не в пример богаче.
Maxwp расскажите, как у вас организован R&D, чем он отличается от производства, как устанавливаете сроки и как их выдерживаете?
Это тянет на отдельную статью, постараюсь ответить в ближайшее время.
Основная идея:
1. те кто способны придумывать задачи, не способны качественно и стабильно их выполнять. Поэтому, это разные люди.
2. если поставить задачу «придумать 100 фишек за день», то это сначала кажется не реальным, но когда ситуация безвыходная, мозг придумывает решение и выдает 100 фишек. Потом при помощи SWOT отбираем нужные, расписываем в production «что и как надо сделать».
Основная идея:
1. те кто способны придумывать задачи, не способны качественно и стабильно их выполнять. Поэтому, это разные люди.
2. если поставить задачу «придумать 100 фишек за день», то это сначала кажется не реальным, но когда ситуация безвыходная, мозг придумывает решение и выдает 100 фишек. Потом при помощи SWOT отбираем нужные, расписываем в production «что и как надо сделать».
Было бы здорово прочитать в новой статье.
Регулярно слышу от других людей про разделение на тех кто придумывает и на тех кто пишет — за исключением очень редких случаев это просто не работает. По моему опыту продукт такого симбиоза получается не просто с багами а опасно нестабильным. Архитекторы которые сами не участвуют в написании кода проекта — жалкое зрелище. Впрочем как и кодеры, которые понятия не имеют как их код взаимодействуют со связанными компонентами.
Может конечно у Вас более позитивный опыт — очень хотелось бы почитать.
Может конечно у Вас более позитивный опыт — очень хотелось бы почитать.
Sign up to leave a comment.
Производство управляет компанией или компания производством?