Проблеми TypeScript у світі React-додатків вiд Iллi Климова на React fwdays | 27 березня
×Закрыть

Процесс или результат?

Интересная вещь, много раз слышал фразу «Эти ребята слишком много уделяют внимания процессу, а не результату». Под процессом я имею ввиду некие «ритуалы», которые мы обязаны выполнять — митинги, планирование, отчётность, ревью, гонять тикеты и так далее — строго по «расписанию», а не «когда вспомню»

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

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Мне кажется, что ответ на этот сложный вопрос — прост, как наверно, и большинство ответов на сложные вопросы...

Налаженный процесс регулирует повторяемость результата. Если во главу угла ставится цель без процесса, то любой проект нужно начинать с чистого листа, а это затратнее. Материально или морально, что в итоге тоже материально затратно. Если цель — процесс, то настройка его гарантирует повторяемость, только непонятно чего именно.

То есть все просто — нужно настроить процесс, ориентированный на результат. И этих методологий — огромное количество. Только корифеи настройки этих процессов совсем не гарантируют, что результат будет работать прямо их коробки на все 100%. Многие говорят — настраивайте под свою специфику, вот у меня так получилось. И даже делятся рецептом.

И если анализировать эти рецепты, то в каждом, даже самом гибком процессе есть то, что ни при каких условиях нарушать не стоит. В этом, наверно, и есть искусство — найти те аксиомы, которые будут поддерживать стабильность, предсказуемость гибкости процесса, нацеленного на результат... И можно делиться своим рецептом.

Процесс создания продукта неотделим от самого продукта. Дизайн продукта включает в себя и дизайн процесса его производства. Почему софт должен быть исключением?

Поэтому, для каждого продукта хорошо бы придумать свой процесс. О чем собственно вещал почитаемый аджайлистами Alistair Cockburn еще году так в 2001. При этом он может быть более или менее тяжелым, смотря по ситуации. Процесс типа «спроси у СТО, и сиди педаль, а там посмотрим» — тоже вполне себе процесс, и часто работает.

спроси у СТО, и сиди педаль, а там посмотрим
Неа, не работает. Во-первых СТО не знает всех тонкостей продукта, так что спрашивать надо СЕО/СОО. Во вторых, вот так сходу, все тонкости не вспомнишь. В третьих — всё не запомнишь.

Ну и самое главное, если у вас в команде будет 10 человек — топ менеджер задолбается всем обьяснять.

P.S. всё выше перечисленное из собственного опыта. Работа значительно ускорилась, стоило только завести «письменные» юзер стори.

Так я ж не спорю, у меня была команда в 30 чел., и я даже сначала не всегда знал как их всех зовут, тут о таком не может быть и речи :) To each his own, в команде из 3-х человек будет работать, вполне.

в команде из 3-х человек будет работать, вполне
тоже не работает. Ответственный манагер, как не странно, тоже занят какой-то работой. Значит постоянно его дёргать — мешать ему выполнять свои обязанности. Кроме того, манагера может просто не быть на рабочем месте (на старте проекта, основная обязанность СЕО/СОО — поиск контактов, общение с пользователями). Всё это приводит к большим задержкам. Ну и самое главное — «спросил-ответил» — это никакой ответственности. Поэтому сегодня и завтра ответы могут быть разными, на один и тот же вопрос.

Так что такой подход работает только в «команде» из одного человека — сам у себя спросил, сам себе ответил.

Совсем без процесса наверное нельзя.
Как показывает практика, даже работая совсем в одиночку, очень полезно иметь некоторый план, и следить за прогрессом.
Но комманда ориентированная на результат будет стараться процесс подстроить под себя, все остальные будут говорить аля «что же это за скарам, если не перемещать бумажки по доске».

Наблюдал такую команду (на результат). Самое смешное было то, что результат был. Вот только он оказывался не тем, что был нужен фирме. Т.е. пока ребята самозабвенно пилили второстепенную фичу, или рефакторили код — компания ждала основной функционал.

Значит у вас был плохой продакт овнер (в терменологии скрама), или проще говоря небыло налаженно нормальной комуникации между компанией и коммандой.

Т.е плохо налаженный процесс (коммуникация — это часть процесса). Да, абсолютно верно. Скрамом там и не пахло, была работа «от забора до обеда».

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

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

Очень советую почитать New Employee Handbook от Valve.
// присоединяйтесь к рекомендации, кто читал.

Читал, во многом согласен (при соблюдении условий а-ля valve), остался только вопрос, какова же лучшая организация внутри команды?

Нет единого рецепта. Люди-то разные. Можно работать в конфликте, можно внедрять уравниловку и решать всё на высоком уровне. Не обязательно делать жёстко на 100% как там, можно на 15% или 50/50. Ведь в Valve тоже не всех подряд берут, и точно так же есть люди которые оттуда уходят.
Мне понравилось, что Valve с ходу разъясняет вопросы «что если я буду не прав?», «что если мы все будем не правы?». А ну, задайте-ка этот вопрос в каком-нить лидере рынка. И тихо-тихо так сами себе задайте главный вопрос: «а что, если рынок будет не прав?». Да-да, те самые миллион леммингов.

а что, если рынок будет не прав
А что Вы вкладываете в это понятие? С моей точки зрения — рынок — это отражение обьективной реальности, поэтому Ваш вопрос звучит как минимум странно

У каждого ответ свой. Самим себе, и без громких слов.
Свой ответ я могу назвать лишь людям, с которыми в одной лодке. Могу лишь заверить, что так бывает. А объективной реальности не существует, это понятие служит лишь для ограничения области определения модели.

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

Без процесса не возможен результат. Главное не ставить превыше результата процесс

Главное не ставить превыше результата процесс
Ок, что лучше:
1. хороший результат в этом месяце, но фиг его знает, как так получилось
2. Слабенький результат, но у нас есть выстроенный, полностью расписанный процесс

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

Мне кажется, приличный результат и есть критерий того, что процесс идет нормально.
Нет, приличный временный результат может быть причиной накопления технического долга. Так и делаются факапы:
первый месяц — полёт нормальный
второй месяц — чуть притормозили, потом наверстаем
Третий месяц — кажется мы намудрили... Надо всё переписывать.
Если процесс могуче расписан, а результат так себе, то и процесс нуждается в доработке, хоть и расписан.
Верно. И самое главное — мы видим, где мы получили задержку. А значит и можем её устранить.
Нет, приличный временный результат может быть причиной накопления технического долга.
Что скорее всего отражает несовершенство оценки результата. Если оценивать просто объем без учета приоритета задач, степени тестового покрытия, интеграционного тестирования, производительности, инсталлируемости в требуемом целевом диапазоне и качества самого кода (ревю) — получается одно, а если с учетом, то другое. Подобно как проигрышная биржевая стратегия без учета некоторых расходов может казаться выигрышной. Почему в первом месяце полет нормальный? Например, делали то, что понятно как делать, обходя и откладывая критические вопросы на потом. Процесс — не панацея, качество разработчиков им трудно компенсировать. К тому же, любой процесс влечет накладные расходы на свою организацию. Как в государстве — мало бюрократии плохо, много — еще хуже. Только постоянный мониторинг результата позволяет поддерживать баланс.

Да, процесс без обратной связи не имеет смысла.
Процесс->результат->улучшение->результат->улучшение->результат и так далее.

Пусть с первого раза идеал и не получится, но будет предсказуемость

Но возможно ли получение хорошего результата без налаженного, отработанного процесса?
Возможно. Встречается редко. Под силу единицам. В Украинских реалиях не встречается (единичные исключения, конечно, возможны).
Примеры такого в жизни — компания valve, известная многим.

В valve я к сожалению не работал, но сдаётся мне, что если каждый делает, что ему вздумается, и когда ему вздумается — дело не будет. Даже шкаф с таким подходом на этаж не затащишь.

P.S. всё таки даже valve имеет внутри команды, которые имеют внутренюю организацию. Так что «результат через бардак» — это не про них.

В valve я к сожалению не работал, но сдаётся мне, что если каждый делает, что ему вздумается, и когда ему вздумается — дело не будет. Даже шкаф с таким подходом на этаж не затащишь.
Суть не в этом, а том что все и так знают что им делать когда и как и это эффективно работает + схема работы «без боссов».
Поищи статью о них, очень поучительно.
P.S. всё таки даже valve имеет внутри команды, которые имеют внутренюю организацию. Так что «результат через бардак» — это не про них.
А кто говорил бардак? — У них хаос, но организованный. А это совсем не бардак. ;) Бардак — беспорядочность.

Казалось бы, при чем тут ожидание Half-Life 3, к процессу работы в Valve :)

Организованный — это и есть процесс. А где Вы у меня нашли хоть слово об обязательной иерархии?

Организованный хаос — это оксюморон, типа горячий лед или живой мертвец. Эффектно, но непонятно.

Живые организмы так устроены. Клетки не отчитываются друг перед другом. Цена вопроса — избыточная информация в ДНК, избыточное время на развитие (миллиарды лет). Однако, процесс прекрасно воспроизводится. И если нужно приготовить хлеб — Вы просто бросаете компоненты в хлебопечку, и дрожжи в «хаосе» дают статистически предсказуемый результат. При этом происходит бесчисленное множество неконтролируемых процессов, а достигнуть результата может и семилетний ребёнок.

Кухарка может управлять государством. ©лысый

Живые организмы
Это как раз идеальный пример отлаженного процесса. Каждая ячейка делает только то что должна, и подчиняется «приказам» в виде гармонов, вплоть до самоубийства. Самодеятельность либо уничтожается имунной системой, либо приводит к смерти организма

Хаос по определению — противоположность порядка. Это не скрытый порядок, не сложный порядок, а просто отсутствие такового, Япония после землетрясения. Клетки не отчитываются, не пьют кофе и сериалов они тоже не смотрят, зато всячески взаимодействуют друг с другом, имеют специализацию, образуют сложные многоуровневые структуры и служат функциональными элементами разнообразных производственных циклов. Технология выпечки хлеба все рано технология, а не вали кулем — потом разберем. Автор справедливо заметил, что никак и не настаивал на построении иерархии процесса брожения, но надо ж как-то хоть мониторить то, что там бродит.

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

В теории хаоса используются аттракторы, которые суть — множество состояний к которому «стремиться» нелинейная динамическая система. Именно поэтому говорят что хаос — скрытый порядок.

Если такова цена успеха — то затаскивание шкафа вполне можно отдать на аутсорсинг. Не просто можно — здесь это очевидно.

Приведу контрастный пример: армия. Там все делают то, что прикажут. Результат — она экономически неэффективна, и все только и занимаются тем что копают «от меня и до следующего дуба».

Вы куда хотите пойти работать — в Valve или в армию?
А теперь представьте на минуту, что существуют военные организации с тем же принципом. Наполеон тоже не верил :)

Если такова цена успеха — то затаскивание шкафа вполне можно отдать на аутсорсинг. Не просто можно — здесь это очевидно.
Которые тоже не могут справится, т.к. используют прогрессивную методику, ага? Программы то делать проще, это вам не шкафы таскать.
Приведу контрастный пример: армия. Там все делают то, что прикажут. Результат — она экономически неэффективна, и все только и занимаются тем что копают «от меня и до следующего дуба».
Простите — что? Армия — это инструмент, который задействуется по мере необходимости. Ни о какой экономической эффективности и речи быть не может. По крайней мере, если речь об армии как таковой, а не о достижении экономических целей путём вооружённых конфликтов.

Более верный пример — организация на пиратских кораблях. Вот там была и экономическая эффективность, и полная демократия, и, как ни странно, железный порядок.

Кстати, именно из военных организаций растут ноги у риск менеджмента

Верно! Это две стороны одной медали. Ни о какой демократии не может идти и речи, если она не может оперативно формировать иерархическую структуру.
Хаос — лишь иллюзия, создаваемая непониманием процесса. Как магия в руках фокусника. В действительности, управление имеет место, просто оно находится на более высоком уровне. И достигается ценой перекладывания (делегирования) низкоуровневых управленческих функций как можно ниже.

Рынок работает примерно так же: каждый сам устанавливает цену, решает что продавать и кому. Но язык не повернётся назвать его хаосом, наоборот, это образец статистического предсказателя. Коллективный разум. Обладающий порой поразительной оперативностью в вопросах принятия решений. Но... ценой уничтожения ключевых ценностей. Ведь за деньги можно купить всё, и что во много крат хуже — продать. Деньги могут служить оправданием сколько угодно неприемлемого (в долгосрочной перспективе) риска.

Нет выбора «процесс или результат». Есть риск-менеджмент. И это процесс. Предсказуемость и монетизация — его результат.

Вот тут поправочка — в Valve есть процесс. Просто его сделали не на формальной логике, а с использованием социальных стандартов. Разработанных столетиями исторических традиций.
Больше скажу — Valve не исключение, их подход воспроизводим и будет воспроизведён ещё не раз. Частично его можно увидеть в любой структуре, но как они сами пишут — у них он занимает 100% времени.

Есть достаточно фундаментальная книга в этом вопросе — «Построенные навечно». Рекомендую прочесть по диагонали, выхватив ключевые идеи. Главная из которых — это возможно, и это работает, и результат процесса хорошо продаётся. Если не поддаваться соблазну добавить ложку дёгтя.

Возможно, но наличие налаженных процессов позволяет увеличить вероятность хорошего результата.
Об этом утверждает, например, модель CMM. ru.wikipedia.org/..._Maturity_Model

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

Говорят, что успехи японской и корейской экономики во многом обязаны философии «Кайдзен» — т.е. постоянному совершенствованию процесса. Вы считаете, они ошибались?

P.S. Я много раз слышал, что «высококвалифицированой команде» не нужны методологии, менеджеры, встречи и так далее. Но я никогда в жизни такую команду не видел.

не нужны методологии, менеджеры, встречи

может быть это из-за того, что нередко бывает неправильное применение методологий, бездарные менеджеры и бесполезные встречи?

бывают, конечно. Как и плохие программисты. Считаете лучше вообще без них? :)

Да, без плохих программистов, бездарных менеджеров и бесполезных встреч лучше.

Конечно, кто же спорит :)

Вот только знаете в чём главная разница между гаражной сборкой(классический пример «без процесса») и конвеерной(хорошо поставленный процесс)?

Лучше поделитесь своими конкретными успехами и best practices в процессостроении, реальные истории реальных людей интереснее читать, чем абстрактные размышления.

Если бы я был идеалом — то наверное бы не парился писать тут :)

Я работал в команде «без процесса», по принципу — подходи, спрашивай у СЕО/СОО и делай. Результат — 50% наработок в мусор, дедлайн просрочен вдвое.

Канбан — скорость вроде ок, предсказуемость страдает.

Скрам — предсказуемость отличная. Скорость — чуть ниже чем при канбан

в чём главная разница между гаражной сборкой(классический пример «без процесса») и конвеерной(хорошо поставленный процесс)?
в чем?

А вы видели, как босс-кореец бросает айфоном в голову и при этом орёт? Это в Киеве кстати...

И вообще, посетите какую-нибудь азиатскую конференцию где-нибудь в Сингапуре — там вам расскажут про Blue Ocean Red Ocean etc. Кайдзен, наверное, уже не актуален...

А вы видели, как босс-кореец бросает айфоном в голову и при этом орёт? Это в Киеве кстати...
И что это меняет?

И да, не стоить путать маркетинговые стратегии с философией организации процесса производства. А то скоро и аджаил будет не актуален, потому что есть Google adwords

яйцо. курица. глупости. да еще и свиньи — все в одном..."успехи японской и корейской экономики", а также сам факт существоания Кайдзен-или-как-там связаны с тем, что эти успехи имеют место в Японии и Корее, а не с тем что современные программисты этих стран не могут обойтись без Кайдзена этого...

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

И да, не перепутаешь...
А перепутаешь, так точно скрум мастером станешь )

Я считаю, что успехи японской и корейской экономики обусловлены не какой-то там философией, а гораздо более прозаическими несколькими десятилетиями вжобывания и помощью штатов, растивших противовес Китаю на Дальнем Востоке.

Нет-нет, во-первых, не просто «высококвалифицированной», а именно «небольшой высококвалифицированной». Во-вторых, не то чтобы совсем не нужны, просто бюрократии нужно сильно меньше.

У немцев бюрократии больше. Вжобывания не больше. Но вот с образованием ситуация в корне противоположна нашей, и тем более китайской модели.

Как раз тот случай, когда стоит изучать, стоит наследовать. А если есть возможность — ещё и получить образование их способом.

Разверните мысль мысль, пожалуйста. С чего стоит брать пример. Пока, все что я знаю о немцах — зарплаты у них (у программеров) ниже чем в Москве, налоги и жилье дороже и никто туда не едет, предпочитая штаты.

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

Логично и то, что система образования, построенная «для своих», создаёт барьеры для чужих (которые в ней не участвовали). Та самая бюрократия.

По поводу налогов — всё относительно. К примеру, мед.обслуживание у немцев на высоте, да и Швейцария под боком. Дороги — отдельная сказка. Немцу рады в любой стране мира. Да и налоговую систему нужно хорошо изучить, чтобы стать её участникам — бюрократия (как впрочем и везде).

Зарплаты программеров ниже — это не минус государству, а плюс системе образования. Да, способна обеспечить себя кадрами на должном уровне, что тут такого? У нас это тоже произойдёт. Даже больше скажу, будь у нас основной бизнес на уровне Германии, ITшники получали бы меньше.

Экология у них и в Штатах — это 2 большие разницы. С нашей и сравнивать не приходится. Да, это стоит денег, но это того стоит!

И всё-таки Евросоюз [сколько ему осталось — вопрос отдельный]. Фактически доступ к отношения в пределах всего союза, а не только одной страны.

Недостатки есть, и серьёзны:
1) Ты ещё войди в ту систему! Если даже немцам это непросто, и самого детства приходится понимать необходимость приспосабливаться к системе.
2) Понаехавшие. Труков там едва ли не больше немцев. Впрочем, и «наших» немало, но... евреев. Особенности еврейской социальной жизни и способов приспособиться обсуждать не будем, просто факт что они там есть. Как, впрочем, и здесь.

Существенный плюс: дешевизна денег. Взять в кредит можно под достаточно низкий процент.

Лично я не рассматриваю страну как объект возможного переезда, потому что надо учить немецкий. Однако внедрить их технологии в вопросах экологии, образования, дорожного строительства, промышленного производства, и конечно же медицины — стоит. Правоохранительную систему — давно пора (Луценко, ховайся в жито).

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

© agilemanifesto.org

митинги, планирование, отчётность, ревью, гонять тикеты

Можно по каждому пункту попробовать задать себе вопрос — «Зачем?»

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

Ещё более правильный вопрос — для кого?
Попали «в яблочко», приведя пример Valve, где каждый вынужден задаваться этим вопросом прежде чем вообще что-то делать. И делать это каждый день.

Многие программисты настолько асоциальны, что вопрос «для кого» для них будет бессмысленныи или нерелевантным, в отличие от «зачем».

Напомни, сколько нас «асоциальных» в сообществе dou? И так, просто представь вживую, сколько это людей. Профессия заставляет быть зависимыми друг от друга, работать в команде, использовать труд и опыт сотен тысяч людей. Вообще-то, мы уже десятки лет меняем социальное устройство этого мира.
Раньше: Хочешь изменить мир — начни с себя!
Сейчас: Хочешь изменить мир — найми программистов!

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

В общем-то, это и неплохо. Пока они так считают, «асоциальными» их не назовёшь.
Другое дело админы. Это такие же IT-ники как и программисты, с уровнем знаний зачастую повыше. Однако считающие главной целью — стабильность, а врагами народа — даже не юзеров, а программистов.Тестировщики дефакто те же админы, но с правом анально карать своих врагов.

А ещё дизайнеры, саппорт, манагеры, писаки, раскрутчики, продавайцы и внедряльщики всего этого счастья в жизнь. В общем, любой социальной группе фору дадим. А ещё у нас есть железо и софт на вооружении, котрые делают весь процесс лёгким и приятным. Пора, наконец, признать, что этот мир мы прогибали под себя. И мы только начали!

Welcome to Тёмное царство!
// Возьми монтировку всяк сюда входящий

Подписаться на комментарии