Рекомендации по построению владельческого бизнеса.

[inbelousov]

С добрым утром, коллеги и друзья!

На протяжении полутора лет я рассказываю как и почему у меня получилось построить прозрачный владельческий бизнес.
Рассказываю только о том, что сам внедрил у себя и проверил всё на практике. В моём журнале нет ничего такого, что не было бы проверено на практике. Нет ничего такого, что не дало бы результат.

Основа

Comments

[astrahan_in]

Ваш пост про PR был очень логичен и понятен, учитывая все записи на тему ТЭБ в которых не раз вы упоминали про данную концепцию "измерить = управлять".

Но вот сидел вчера голову ломал, как измерить продукт программиста/команды программистов?
Количество строчек кода? Количество функционала в ПО? Количество багов?
Давайте подумаем так как же?

[pavel_koryagin]

Давайте. Как раз сейчас переписываю код за сотрудником и наглядно смотрю, что же можно было бы ввести в систему контроля.

Пока видится такая штука, как количество отступлений от стандартов, которые он не может мотивировать. Это всего один аспект, но идея себя наглядно иллюстрирует.

Впрочем, здесь вырастает специфика. Если для программиста в веб-студии гораздо важнее сколько он веб-страниц/плагинов за единицу времени выдал, то для разработчика в сложном проекте (у меня) это далеко не единственное главное. Более того, как измерить продукт я пока не придумал - работаем, как работается. А вот критерии сопутствующих проблем, снижающие рентабельность и качество итогового продукта - уже начинают обрисовываться.

Далее туда же, количество "забытых" тезисов из ТЗ. Количество отпущенных багов в типовых юз-кейсах.

За баги в хитрых юз-кейсах тянуть не вижу смысла - там от ошибки до вилимого бага слишком долгая и неочевидная цепочка.

[astrov]

может измерять количество законченного продукта за какое то время (http://www.artlebedev.ru/kovodstvo/sections/148/)

[levaal]

Да, по-моему подходит на роль кандидата продукта для айтишников.
Разработка одного проекта была основана на user stories, которые оценивались в story points. Вот эти самые story points и можно учитывать как продукт.

Теперь надо подумать как прикрутить качество разработки к этому, чтобы не гнались закрыть как можно больше предметов, а потом чтобы всплывала куча багов.

Так же в систему надо добавить лида - зачастую он вообще не пишет код, консультирует разработчиков и общается с клиентом. Тут другой продукт нужен.

[pavel_koryagin]

Спасибо. Нашёл пищу для ума. Кое-какие идеи нарисовываются.

[pavel_koryagin]

Также в моём комментарии можно увидеть проблему: я не пока вижу какие достижения можно измерять. В кандидатах на учёт только ущерб.

[gloria_mundi_]

ничего сложного нет - см. ниже.

[gloria_mundi_]

На самом деле в it все тоже довольно просто. С одним маленьким НО. Для того, чтобы оценивать продукт программиста\сисадмина нужно первоначально создать условия для оценки этого продукта

[pavel_koryagin]

Для программиста Вы описали конкретный бизнес-процесс. Тут да, всё красиво. Но при перекладывании на конкретную команду возникают нюансы.

Для себя понял, что нужно сосредоточиться на отладке роли аналитика. Отдельной ставки у нас быть не может, размер команды не тот. Но бизнес-процесс на эту роль явно стихийный.

Отсюда и следует, что замерять нечего, так как предлагаемые Вами вещи для моей команды ещё пока в лежат в будущем.

Спасибо. Вроде знал про аналитиков, а как-то вылетело.

Тем не менее, бывают разработчики, которые успешно совмещают функции аналитика (архитектора) и разработчика. Эти люди гораздо эффективнее, но очень редки. Если такой есть, то его в схему с аналитиками запихать тоже особая задача. Возможно даже не стоит этого делать.