Комментарии 72
Может ли быть аутсорс — внутренним для компании? — Легко. А внешним? — тут сложнее, права, безопасность это всё… но возможно! А внутренним и внешним? — Можно и вот как это сделать.
Короткий ответ: нифига не легко, и то, что вы написали, не «взлетит».
Чуть более развёрнутый ответ: обезличенный исполнитель в пуле никак не гарантирует ни качества, ни сроков исполнения, а система рейтингов в скором времени приведёт лишь к тому, что в системе сформируется группа очень востребованных и очень дорогих лидеров, и большой пул аутсайдеров-тёмных лошадок.
Второй момент, почему это не заменит, по крайней мере, внутреннюю разработку: аутсорс требует достаточно высокой степени формализации взаимодействия между заказчиком и исполнителем. Во многих конторах, которые имеют внутренние отделы разработки, коммуникация между заказчиком и исполнителем крайне упрощена. Они не будут готовы этим жертвовать.
Третий момент — сложность и ненадёжность администрирования всего этого колхоза.
Про группу лидеров полностью согласен, наглядно на хабр фрилансе представлена. А вот с аутсорсом все не так плохо, если аутсорсить много. Например, департамент по частям — руки (field service), процессы (service management), эксплуатация (operations), разработка и развитие (development), связи с бизнесом (brm) и управление и планирование (Strategic planning and governanace). И да, это не просто.
обезличенный исполнитель в пуле никак не гарантирует ни качества
Задача не может быть утверждена без ревью, ревью стимулируется у исполнителей набором балов и доступом к другому уровню задач и стоимостей.
ни сроков исполнения
хм… не люблю самоцитирования но
Задача автоматически считается невыполненной если была взята в работу, но сроки выполнения завершились и от исполнителя не было направлено обоснование на продление сроков.
Невыполненная задача устанавливается обратно в пул задач на выполнение, а исполнителю назначается штраф в виде списания балов.
а система рейтингов в скором времени приведёт лишь к тому, что в системе сформируется группа очень востребованных и очень дорогих лидеров, и большой пул аутсайдеров-тёмных лошадок.
И это есть в статье. Для набора рейтинга необходимо решать задачи или ревьювить их, для большой группы не будет хватать задач их уровня, а на нижнем уровне они не будут иметь преимуществ в выборе задач из пула. Просто так сидеть на троне тоже не выйдет потому, что без активности рейтинг снижается. Новички учатся их через ревью менторят старички и это нормально и полезно. Придраться не выйдет так как есть система споров с арбитражем и голосованием.
Третий момент — сложность и ненадёжность администрирования всего этого колхоза.
Любая деятельность отличная от выковыривания сопли из носа имеет сложность и ненадёжность и сопровождается сложностями в администрировании.
Задача не может быть утверждена без ревью
Во-первых, ревью также никак не гарантирует качества, тем более если ревью проводится таким же анонимным исполнителем, пусть и более высокого ранга. Во-вторых, ревью — это оплачиваемая работа, как много клиентов готовы за это платить? Во внутренних проектах ревью вообще скорее исключение, чем правило. В третьих, вот не прошёл какой-то код ревью — а работа-то не выполнена. Заказчику ведь надо было получить решённую задачу, а не ждать, пока там шестеренки между собой порешают, годный код или не годный.
Задача автоматически считается невыполненной если была взята в работу
Эм… это называется «сорваны сроки», так, чтобы вы были в курсе. То, о чём я и пишу. Заказчику, повторюсь ещё раз, решенная задача была нужна. А не «справедливое возмездие» не вложившемуся в сроки исполнителю в виде списания баллов, которого он и видит-то в первый и последний раз.
для большой группы не будет хватать задач их уровня
Почему вы так решили? Говорить о существовании какого-то баланса в достаточно тонкой структуре, которая и существует только как не до конца проработанная концепция, как минимум преждевременно. Тем более что посмотрите на любую биржу фриланса, там аналогичные проблемы и аналогичные тренды.
Любая деятельность отличная от выковыривания сопли из носа имеет сложность и ненадёжность и сопровождается сложностями в администрировании.
Любая. Но время и бюджеты всегда ограничены, а возможности раздувать бюрократию, наворачивая друг на друга цепочки контроля, метрики там всякие, безграничны.
Во-первых, ревью также никак не гарантирует качества, тем более если ревью проводится таким же анонимным исполнителем, пусть и более высокого ранга.
Одним может и нет, двумя и более вполне возможно. Если трое скажут что всё хорошо, такому ревью вероятно стоит доверять. Да и такие вопросы возможно балансировать.
Во-вторых, ревью — это оплачиваемая работа, как много клиентов готовы за это платить?
Конечно оплачиваемая, за ревью можно получить балы, если спери исполнителей нет желающих всегда можно назначить цену и это тоже предмет баланса и настроек. Клиент не готов платить за качество кода? Сомнительно!
Во внутренних проектах ревью вообще скорее исключение, чем правило.
И что? Это проблемы этих внутренних сервисов, есть мировая практика доказавшая свою эффективность и её результатами стоит воспользоваться.
В третьих, вот не прошёл какой-то код ревью — а работа-то не выполнена. Заказчику ведь надо было получить решённую задачу, а не ждать, пока там шестеренки между собой порешают, годный код или не годный.
Заказчик не работает на уровне задач, он работает на уровне сроков и смет, поэтому можно смело это исключить. Зависшая задача — это проблема, но не данной концепции так у всех случается постоянно. Концепция не серебряная пуля которая сделает ваш проект суперменом, она позволяет быстро и эффективно решать проблемы. В рамках описанной концепции проблема ревью задачи решается повышением её привлекательности, тоесть повышением балов или установка стоимости на неё. Как вариант можно иметь команду из разных компетенций и уровней которые в пожарном режиме, за отдельную плату, согласны решать директивные задачи.
Любая. Но время и бюджеты всегда ограничены, а возможности раздувать бюрократию, наворачивая друг на друга цепочки контроля, метрики там всякие, безграничны.
Бюрократия — это система делегирования. На одном её конце полная остановка любых решений на другом полный хаос. Нужно стараться придерживаться середины. Без небольшой бюрократии у вас будет ручной режим управления и микроменеджмент. Если вам такое подходит — работайте так.
Одним может и нет, двумя и более вполне возможно. Если трое скажут что всё хорошо, такому ревью вероятно стоит доверять. Да и такие вопросы возможно балансировать.
Хорошо, следующий вопрос: зачем два и более сеньора будут выверять код неизвестного им миддла или там джуна? Вам не кажется, что такой расход времени квалифицированных специалистов
Конечно оплачиваемая, за ревью можно получить балы
Что значит «получить баллы»? Вы считаете, что сеньоры будут тратить время на выполнение задач-пустышек за виртуальные звёздочки, в то время как они могут тратить время на выполнение оплачиваемых задач?
И что? Это проблемы этих внутренних сервисов, есть мировая практика доказавшая свою эффективность и её результатами стоит воспользоваться.
Что значит «доказавшая свою эффективность»? Код ревью, как и любая другая методика, имеет свои рамки применения, где она эффективна. И за их пределами она неэффективна. Не надо натягивать одну и ту же сову на все глобусы. Если вы хотите продать свой сервис тем, кто сейчас ведёт инхаусную разработку, начинать с убеждения, что дескать вот вам теперь надо платить больше, но это эффективная мировая практика — так себе дебютный номер.
Заказчик не работает на уровне задач, он работает на уровне сроков и смет, поэтому можно смело это исключить.
Как-то слишком вы смелый :) Допустим, я, заказчик, хочу получить проект 01.01.2021, и вы мне что, предлагаете чёрный ящик, в котором оно само с помощью анонимов раздаёт задачи, утверждает их результаты, наказывает в виртуальной «валюте» других анонимов за срывы сроков, потом докладывает мне, что сроки сдвигаются до 01.04.2021 (но тем, кто виноват, баллы сняты)? Спустить на тормозах и ждать результата, дескать, система сама всё порешает? А риски на себя кто брать-то будет? Страховые компании в вашу систему привлекать, что ли?
Подумайте сами, кто в здравом уме захочет этим пользоваться?
Как-то слишком вы смелый :) Допустим, я, заказчик, хочу получить проект 01.01.2021, и вы мне что, предлагаете чёрный ящик, в котором оно само с помощью анонимов раздаёт задачи, утверждает их результаты, наказывает в виртуальной «валюте» других анонимов за срывы сроков, потом докладывает мне, что сроки сдвигаются до 01.04.2021 (но тем, кто виноват, баллы сняты)? Спустить на тормозах и ждать результата, дескать, система сама всё порешает? А риски на себя кто брать-то будет? Страховые компании в вашу систему привлекать, что ли?
Проблема решается вводом в систему гаранта выполнения задачи от исполнителя. Скажем, исполнитель вносит 10% от суммы вознаграждения задачи и если он продалбывает сроки — эти деньги уходят платформе или заказчику. Механизм сразу становится сложнее, но и исполнителю становится архи-невыгодно подставлять заказчика. Заодно и все исполнители мелкие и не способные отсеиваются. Примерно такой же механизм используется на господрядах. Вроде работает. Хотел бы ли я видеть его на биржах — ну, в целом, по четко поставленным задачам, где нет высокой доли неопределенности — почему нет
Примерно такой же механизм используется на господрядах. Вроде работает
Это хорошо работает, когда проект детерминированный. Вы вряд ли ошибётесь со сроками укладки 1000 кубов бетона, зная объемы поставок бетона, производительность вашего бетононасоса, и имея ещё один в резерве на случай поломки. Если же проект включает R&D, тут два варианта: либо сразу заложить в стоимость все риски и увести его в ценовой космос, либо лояльно относиться к обоснованным сдвигам сроков. У обоих подходов свои минусы, но вторые куда более конкурентоспособны.
Озвученные проблемы актуальны в нашей области, наверное, с 60х годов. В области всякого изобретательства и конструирования с середины 19 века. Мне интересно услышать мнение автора — почему за почти 200 лет никто не додумался так работать и не получил все те бонусы и плюшки, о которых в статье говориться?
Как связан интернет с проблемой определения статуса задачи? Или с проблемой контроля качества? Вы же эти проблемы обещаете решить, а не проблему «послать сообщение, поставить задачу через интернет».
Как связан интернет с проблемой определения статуса задачи? Или с проблемой контроля качества? Вы же эти проблемы обещаете решить, а не проблему «послать сообщение, поставить задачу через интернет».
Не уверен что правильно понял вопрос, но концепция призвана решить не глобальные проблемы столетия, а несколько конкретных проблем. По «статусу задачи» пожалуйста напишите вопрос более развёрнуто, что конкретно вас заинтересовало. Контроль качества осуществляется так же как и раньше для тех же задач, но уже систематизировано по ясным критериям большим количеством людей коллегиально.
Статус задачи — программист говорит, что уже почти готово. Или говорит что готово, а оно не работает. Или работает, но не так как надо. А когда об этом начинаем говорить, то оказывается, что это изменение требований.
Качество — программисты не знают зачем и как будет использоваться система и в итоге делают глупые ошибки с точки зрения UX и логики. Тестеры, которые тоже в предметной области непонимают не могут такие ошибки отловить.
Статус задачи — программист говорит, что уже почти готово. Или говорит что готово, а оно не работает. Или работает, но не так как надо. А когда об этом начинаем говорить, то оказывается, что это изменение требований.
У поставленной задачи есть критерии оценки выполнения — это время, соответствие код конвеншену, пройденные Unit тесты, пройденное ревью, опционально(потребляемые кодом ресурсы или время выполнения). Если решение соответствует критериям — значит оно выполнено верно и должно быть оплачено. Исполнитель имеет право вернуть задачу постановщику с указанием ошибок или неточностей, неоднозначных трактовок. Постановщик правит задачу или заводит спор с арбитражем. Постановщик не может задним числом исправить задачу если она не была передана ему на ревью от исполнителя, поэтому никаких дополнительных требований в задаче быть не должно.
Качество — программисты не знают зачем и как будет использоваться система и в итоге делают глупые ошибки с точки зрения UX и логики.
Это решается с помощью чёткой постановки задачи с необходимым уровнем декомпозиции. Декомпозицию делают специалисты компетенция которых(отсутствие возвратов на доработку) позволяет оформлять задачу правильно. Конечная задача представляет из себя описание данных на входе и выходе, интерфейсы, используемые библиотеки и технологии, параметры быстродействия и т.д. Если на задачу должным образом оформлена документация с схемами движения данных, есть описание архитектуры модуля и обоснование, то ошибок логики быть не должно, а уровень входа исполнителя в задачу будет низким.
Тестеры, которые тоже в предметной области непонимают не могут такие ошибки отловить.
У QA должны быть документы от разработчиков для составления чек-листа или в некоторых случаях сами разработчики составляют такие списки, это тоже можно предусмотреть в задаче.
У поставленной задачи есть критерии оценки выполнения — это время, соответствие код конвеншену, пройденные Unit тесты
Как у вас всё просто :) А если правильность выполнения задачи может быть оценена только после интеграционного тестирования софта? А если правильность выполнения задачи может оценить только конечный пользователь? Самый типичный пример — какой-нибудь пользовательский репорт, для которого юнит-тесты отсутствуют как класс, да или хотя бы страница сайта.
Если на задачу должным образом оформлена документация с схемами движения данных, есть описание архитектуры модуля и обоснование, то ошибок логики быть не должно
А вы слышали про такую штуку, как Agile? Знаете, зачем вообще появился и стал настолько популярен вот такой навороченный комплекс этих методик? Потому что бизнес оказался неспособен должным образом формулировать корректные и подробные требования к софту. А софт, блин, писать надо в любых условиях. И вот индустрия была вынуждена выработать адаптивный подход, который позволял бы работать с нечёткими и постоянно меняющимися требованиями.
А вы сочинили динозавра, завязанного на чёткую формулировку задач, детальные спецификации, хороший и ответственный контроль и прочие штуки, которые в реальной жизни не встречаются. Ваша система очень волатильна к человеческому фактору. Любое звено даст сбой, и проект развалится. А оно получит баллы в минус, помашет ручкой и пойдёт на Апворкс.
А вы слышали про такую штуку, как Agile? Знаете, зачем вообще появился и стал настолько популярен вот такой навороченный комплекс этих методик?
Agile и его манифест крайне спорная вещь и по моему мнению приносит больше проблем чем их решает. Как-то до него всё работало, но тут профсоюз программистов победил и продавил.
Как по мне, то это не программисты продавили, а бизнес, начав наступление, дошёл "до Волги" и был отброшен "до Москвы" :)
Agile и его манифест крайне спорная вещь и по моему мнению приносит больше проблем чем их решает
Я абсолютно с вами согласен, что вещь спорная, и имеет массу проблем (правда не готов сказать, что их всё-таки больше, чем они решают :-). Но гибкий подход сам по себе возник, существует и успешно продаётся по уже упомянутой объективной причине: в реальных софтверных проектах крайне редко бывают четкие и полностью сформулированные спецификации, а так, чтобы они с самого начала ещё и неизменными были — это вообще утопия. А для вашей системы это краеугольный камень. Чтобы работало, все должны писать хорошие спеки, контролировать, одни люди давать качественные эстимейты, другие в них укладываться. Да так не бывает в жизни, да и попробуйте ещё хоть одного вменяемого программиста найти, который положит свои
А для вашей системы это краеугольный камень.
Нет. В статье чёрным по белому написано
Каждая задача и декомпозиционное дерево задач сопровождается созданием набора документов обосновывающих выбор решения и кратко описывающих его. Каждая задача не являющаяся веткой уже существующей, то есть расширение функционала — должна начинаться с утверждения у менеджера и далее проходить утверждения по ролям вплоть до конечного исполнителя.
То есть — изменились требования, формализуем их отправляем на самый верх дерева для утверждения менеджером (нужно ли, на что влияет и т.д.), далее функционал анализирует архитектор на предмет возможности внедрения, проблем при интеграции, совместимость с легаси и утверждает, далее задача падает вниз на декомпозицию. Всё достаточно просто и логично, защищено от бездумного и опасного внесения функционала и рефакторинга.
а) Корректная их формулировка/формализация
б) Корректная оценка менеджером (со стороны исполнителя же? Т.е. там должен быть компетентный для этого руководитель проекта)
в) Оценка архитектора, причём всесторонняя
г) Ещё какие-нибудь роли тимлидов/сеньоров/кого-то
д) Собственно исполнитель
И на каждом этапе соответствующий участник должен компетентно и качественно выполнить свою роль, иначе вся цепочка поломается. Неужели вы сами не видите, сколько в этой цепочке возможных точек отказа, какой оверхед рабочего времени, и насколько она неповоротлива?
Это все до крайности наивно. Четкие декомпозиции, критерии, постановщики задач и прочее, в отдельной ИТ системе не нуждаются. Эти процессы прекрасно могут работать в среде с бумагой и почтовыми голубями. И тут хочется вернуться к изначальному вопросу
Мне интересно услышать мнение автора — почему за почти 200 лет никто не додумался так работать и не получил все те бонусы и плюшки, о которых в статье говориться?
Конечная задача представляет из себя описание данных на входе и выходе, интерфейсы, используемые библиотеки и технологии, параметры быстродействия и т.д. Если на задачу должным образом оформлена документация с схемами движения данных, есть описание архитектуры модуля и обоснование, то ошибок логики быть не должно, а уровень входа исполнителя в задачу будет низким.
А не окажется ли, что своё понимание задачи компетентному специалисту будет проще выразить, решив её, а не описывая для исполнителя с очень низким уровнем?
И что случится, если опишет таки при декомпозиции, её выполнят, но конечный результат заказчика не устроит — "декомпозитор" неправильно понял основную задачу?
И что случится, если опишет таки при декомпозиции, её выполнят, но конечный результат заказчика не устроит — «декомпозитор» неправильно понял основную задачу?
Над «декомпозитором»(так же как и над любой другой ролью) находится тот кто поставил задачу и который апрувит решение. Решение ревьювят исполнители с той же ролью плюс на одну выше и ниже. Некачественное решение не пройдёт утверждение у постановщика задачи и не пройдёт ревью.
Некачественное решение не пройдёт утверждение у постановщика задачи
Смотрите: если конечная цель проекта ехать (т.е. решить какую-либо бизнес-задачу), а не шашечки (обеспечить формальную приёмку задач), то постановщик задачи и лицо, компетентное аппрувить результат её выполнения — это в общем случае две разные роли, далеко не всегда сочетающиеся в одном лице. Постановщик — это некий вышестоящий ИТ-специалист или аналитик. Аппрувер — это конечный бизнес-пользователь. Как это будет у вас реализовано?
Бизнесовый человек, менеджер, поставил задачу на человеческом языке, "декомпозитор" перевёл её на технический и разбил на подзадачи. Что там менеджер будет апрувить?
Это решается с помощью чёткой постановки задачи с необходимым уровнем декомпозиции. Декомпозицию делают специалисты компетенция которых(отсутствие возвратов на доработку) позволяет оформлять задачу правильно. Конечная задача представляет из себя описание данных на входе и выходе, интерфейсы, используемые библиотеки и технологии, параметры быстродействия и т.д. Если на задачу должным образом оформлена документация с схемами движения данных, есть описание архитектуры модуля и обоснование, то ошибок логики быть не должно, а уровень входа исполнителя в задачу будет низким.
Это в идеальном мире так. А обычно заказчик озвучивает максимально общую формулировку. Как один из вариантов — потому что ему не хватает квалификации, не хватает времени (а описать задачу очень подробно — это по сути ее решить и попросту подробное ТЗ это дорого ) или требования меняются на ходу (просто в силу изменчивости нашего мира). И поэтому выгоднее работать не с буквоедами, а с профессионалами по схеме T&M. Все равно воронка такая, что реальных профессионалов в айти очень мало и рано или поздно к ним придёшь, но после халтурщиков ещё и переделывать придётся (=переплатишь в любом случае)
А обычно заказчик озвучивает максимально общую формулировку.
В начале статьи описано попадание этого общего ТЗ на вход сервиса. Декомпозиция начинается не с общей задачи, а составления экономического обоснования. Задача->ЭЭ->ТТ->ТЗ->… конвеер декомпозиции.
требования меняются на ходу
Тоже про это есть. Для этого задача закидыватся с уровня ТЗ на архитектора который может компетентно оценить внедряемость, совместимость и т.д. В итоге у вас нет ситуации адской мешанины из костылей и легаси.
В итоге у вас нет ситуации адской мешанины из костылей и легаси.
Вы, наверное, не понимаете :) Адские машины из костылей и легаси не закладываются на этапе создания проекта. Наоборот, они в большинстве своём начинались с простых, нормально спроектированных проектов, которые отвечали своим требованиям и были современные на момент внедрения. Но многие проекты — они, заразы, живут и развиваются. Меняются бизнес-требования, меняются архитектурные требования, меняются входы и выходы. И вот тут на арену выходят они: сроки и бюджеты. Бизнес уже работает. Он не может ждать, пока один чувак составит хорошее подробное ТЗ, другой чувак компетентно оценит внедряемость и совместимость, выдаст архитектуру под новые требования, на ней третьи чуваки распишут задачи, четвёртые чуваки реализуют их, пятые чуваки составят план миграции со старой системы на новую и выполнят эту самую миграцию, для того, чтобы реализовать какой-то функционал, который плохо вписывается в текущую архитектуру.
Нет, если можно сделать просто костыль, который позволит пусть криво, но поднять нужный функционал на старой системе, так и нужно делать. Считайте это бизнес-требованием, одним из условий задачи, а не какой-то проблемой, которую нужно решать.
Я кто формирует критерии? Заказчик? У него предполагаются подобные компетенции? Я вот со своим опытом не возьмусь сформулировать признаки однозначные формальные критерии даже для простого PHP-кода. Глянуть на него и сказать "попахивает" — могу, даже ткнуть в конкретные места. Но вот формализовать...
Ни одна вменяемая служба безопасности не выпустит ни одну внутреннюю разрабоику наружу.
Это полный бред.
Из описания я понял, что это сервис внутреннего геймдев-а… Только зачем?
Любая инфо система это в первую очередь работа с бэком. Это массивы данных, интеграции внешние и внутренние. Как к этому подключать неизвестных людей без понимания общей концепции и знания внутренней архитектуры?
Документация? Так они пока будут ее изучать любые сроки пройдут. На второй день изучения этот обезличенный кадр плюнет и уйдет в туман.
"писать код" это десятое дело вообще. До этого надо кучу процедур пройти.
В общем данная статья про очередной мегаплан. Писали для себя, а давайте это будем продавать. И пофиг, что разработка очень узкая. Прикрутим пару костылей и можно "грабить корованы".
Очень много моментов вообще не освещено.
Ни одна вменяемая служба безопасности не выпустит ни одну внутреннюю разрабоику наружу.
Это полный бред.
Ну бодишоперы тут с вами поспорят, на аутсорсе огромное количество внутренних разработок по причине описанной мной в начале статьи. Вспомните недавний случай с боингом и индийскими аутсорсерами ПО. А это не просто внутренняя разработка, а критически важная составляющая программно-аппаратного комплекса самолёта.
Из описания я понял, что это сервис внутреннего геймдев-а… Только зачем?
Это описание нового формата отношений в треугольнике заказчик-проект-исполнитель. Это можно применить в широкому спектру задач в том числе и к геймдеву. Геймдев подсдулся в карантин, но сейчас опять начал колоситься, а ресурсы ограничены, если думаете что в этом нет проблемы то вы сильно ошибаетесь.
Любая инфо система это в первую очередь работа с бэком. Это массивы данных, интеграции внешние и внутренние. Как к этому подключать неизвестных людей без понимания общей концепции и знания внутренней архитектуры?
Документация? Так они пока будут ее изучать любые сроки пройдут. На второй день изучения этот обезличенный кадр плюнет и уйдет в туман.
Я боюсь спросить как вы подходите к решению поставленной задачи? Впиливаете что-то без оглядки на легаси и архитектуру? Документация и система знаний проекта это альфа и омега всего проекта он с неё должен начинаться и ею заканчиваться. Человек перед решением задачи должен ознакомиться с обоснованием в документе о её постановке, если остались вопросы — двинуться вверх по дереву поставленных задач к той с которой декомпозировали текущую и прочитать её обоснование. Обычно именно этого и нет и это вызывает такие потери времени и рефакторинг, что хоть святых выноси.
Концепция в примитивном виде внутреннего сервиса уже была реализована в Белоруссии Егором Бугаенко.
Рациональная система управления с численными показателями ведет к «итальянской забастовке» и оптимизации по численным параметрам. Рассказывать стоит о достижении баланса между исполнителями и постановщиками, о предотвращении сговора. И, конечно, помнить, что исполнители (и постановщики) — прежде всего люди, а не работы.
Сговоры отсекаются невозможностью прямой вертикальной коммуникации
Угу, а вместе с ними и обмен опытом, особенно обмен опытом в рамках проекта.
люди тянутся к самосовершенствованию
Это, мягко говоря, неверное утверждение. Даже к Playstation 5 людей тянется поболе, чем к самосовершенствованию.
Угу, а вместе с ними и обмен опытом, особенно обмен опытом в рамках проекта.
Это сделано намеренно и для того, чтобы перенести опыт в текст и схемы из головы. Даже плохой или много текста, плохие схемы лучше чем их отсутствие вместе с носителем. Новичку лучше предоставить структурированную от общего к частному информацию, чем вливать в него фарш в надежде сформировать в его сознании «корову».
Это, мягко говоря, неверное утверждение. Даже к Playstation 5 людей тянется поболе, чем к самосовершенствованию.
Это частное от общего, все хотят стать лучше в своём деле.
Это сделано намеренно и для того, чтобы перенести опыт в текст и схемы из головы. Даже плохой или много текста, плохие схемы лучше чем их отсутствие вместе с носителем.
Интересно, какая цепочка рассуждений вам даёт основание даже не полагать, а хотя бы надеяться, что, убрав самую короткую и простую коммуникацию между сотрудниками, вы получите более качественную передачу информации, чем при наличии этой коммуникации? О_о
Это частное от общего, все хотят стать лучше в своём деле.
Нет. Терминальная стадия — идеальный потребитель, который ничего не создаёт. К сожалению, это животная личина человеческой природы. И никуда от неё не деться. Кто не мечтает лежать на берегу океана на своём острове попивая мохито и загорая на солнышке днями? Да и пофиг, что после нескольких месяцев такого «отдыха» деградируешь вообще окончательно.
Это коммунисты пытались вырастить идейного человека. Все мы помним, чем это закончилось...
Этож как надо выпендриться, чтобы вводить людей в проект по полгода…
>Матрицу компетенций возможно получить в сервисах специализирующихся на тестировании в автоматизированном режиме.
Ох уж эти сказочки, ох уж эти сказочники…
Сложная предметная область, отсутствие внятной архитектуры, документации, политики онбординга, ротации, текучка — и года может не хватить.
Я и на третий день выпускал релизы. Но вот на мало-мальски сложном и неидеальном проекте сделать самостоятельно любую задачу в рамках своих технических компетенций, не спрашивая у остальных программистов "куда рыть" — тут полгода хватило бы хорошо.
Может мы о разных "всё ясно — не всё ясно" говорим? Я не о знании как решить задачу "с нуля" или в идеальной системе, а о том, чтобы при получении задачи на изменение поведения не тратить кучу времени, своего и коллег, на исследования, а где же текущее наблюдаемое поведение зарыто в коде, по каким слоям размазано, куда вносить изменения. И, немаловажно, чётко понимать что твои изменения могут сломать, на что обратить внимание тех же тестировщиков, да и самом хоть бегло проверить, прежде чем отдавать тестировщикам.
Любую предметную область возьмите, где специалисты учатся по 4-6+ лет — с большой вероятностью за полгода простой программист в неё не въедет, имея необходимость параллельно с неидеальной кодовой базой разбираться.
И зачем мне все детали торговли бондами?
Чтоб спроектировать архитектуру решения или модель предметной области, готовую к вероятным изменениям. Сначала бизнес хочет чтоб хоть какие-то детали модель отражала, а потом ему нужно всё больше деталей. И чем больше деталей вы знаете на старте, тем больше вероятность, что сделаете архитектуру или модель такой, что новые хотелки бизнеса будут вести только к добавлению кода, а не изменению, включая переписывание с нуля. Нет?
Вот мне по жизни помогло прохождение курса бухучёта "для себя". Даже сейчас помогает, пускай и планы счетов изменились. А вот несколько проектов в медицинской тематике оставили меня в чётком убеждении, что чтобы эффективно в них работать, в частности выявлять большинство противоречий в постановке задачи на этапе постановки, а не на попытке сдачи, надо какое-то медицинское образование получить, пускай неформальное. Или техническое, но в области биомедицинской информатики или как там его. Но тут сроки совсем другие по сравнению с курсами бухучёта. Или скатиться на выполнение чисто технических, "кодерских" задач, а не инженерных, "программистских", требовать себе "в помощь" (а, скорее, в руководство) какого-то переводчика с языка медицинского "бизнеса" на технический, отказаться от понимания того какие задачи и для кого я решаю.
Ну, практика показывает, что так не бывает. Все равно заранее не угадаешь.
>какого-то переводчика с языка
Ну да. Аналитик называется. Мне с теми же бондами полтора года был нужен — а потом я понял, что при желании справлюсь сам. Ну и справлялся в общем. Но до этого я же уже годами выпускал релизы, и удовлетворял потребности пользователей.
Ну то есть, понятно, что способность, желание и т.п. вникнуть в детали бизнеса — оно всегда хорошо. И на такое вникание может уходить много лет. Ну просто это не обязательно.
Полгода — это много и мало. Все зависит от предметной области и от Вашей роли и Импакта. Вы же ведь не удивляетесь, что в ТК РФ испытательный срок устанавливается в 3 месяца? И мне неизвестны примеры его закрытия заблаговременно? А для должностей уровня C-level там хитрые схемы, когда неудобного и несправляющегося директора могут уволить и через полгода… то же и с ключевыми инженерными ролями. Принеси-подать — можно и через месяц зачастую делать, если задачи дают достаточно декомпозированными и с четкой постановкой
Как обычному сеньору мне испытательный досрочно закрывали за месяц вместо трёх. Без задач с чёткой постановки. А вот с ведущими, пускай и неформально, позициями я бы и сам хотел полгода минимум постфактум.
Удивляет. Во-первых, я сам никогда не вникал в работу столько, во-вторых, те исключительные случаи, когда кто-то испытательный срок не проходил (ну или у меня было четкое решение по этому вопросу, пусть меня и не послушали) все было прекрасно видно через месяц. Закрывать досрочно успешно не приходилось, но скорее всего по той простой причине, что в этом не было никакой необходимости — то есть, такое решение ничего бы не изменило в статусе человека.
Ну то есть, я говорю о своем опыте, не более того — и он мне подсказывает, что и три месяца это много. За это время можно свое впечатление пару раз перепроверить, но обычно первое бывает верным.
>директора
Мы говорили про ИТ, вообще-то, и о вводе человека в проект. В проекте не бывает директоров. Но если вы про директора — то тут да, я пожалуй согласен. Если речь вообще о руководителе, которые не делает что-то своими руками, то сроки могут быть и длинными.
Благодарю за статью.
Во многом резонирует.
Проектирую подобный "чёрный ящик", с приземлением на международную сеть коливингов для разработчиков-digital_nomads (цифровых кочевников).
Буду рад общению и сотрудничеству.
Если я правильно понял статью — это называется краудсорсинг. В России из-за менталитета не взлетит. Была похожая идея (правда более масштабная, не только для разработки), год пытались развить — в России понимания что это такое нет, а вот в Европе пожалуйста. Есть не плохие примеры.
Где глянуть на идею?
+ будет полезно про примеры.
Если я правильно понял статью — это называется краудсорсинг.
Отличие аутсорса и краудсорса в оплате труда. Краудсорсеры — это волонтёры им не платят денег соответственно для логика работы и мотивация другая.
В России из-за менталитета не взлетит.
Можно подробнее что в России не так с менталитетом? И где так? В Европе? Европа большая, Россия тоже европа. Что скажете насчёт испанского и итальянского менталитета и отношения к работе?
Очень было бы интересно посмотреть на работающую модель.
Конечно очень сильно зависит от очень многих факторов — территории где это организовать, направление, количество заказов. Но в общем случае, и я в этом уверен, что даже если удастся запустить данную модель, то уже через полгода (плюс/минус в зависимости от внешних факторов) ее разорвет в клочья!
территории где это организовать
Вся идея была в такой форме организации рабочего процесса при котором исполнители смогут решать задачи доступного им уровня, в которых они наиболее специализированы. По мере выполнения задач исполнители выстроятся в дерево с которым можно решать задачи широкого спектра. Даже если все исполнители всплывут вверх, а внизу никого — они смогут брать задачи уровня ниже но выполнять их на порядок быстрее и качественнее чем новички.
Но в общем случае, и я в этом уверен, что даже если удастся запустить данную модель, то уже через полгода (плюс/минус в зависимости от внешних факторов) ее разорвет в клочья!
Чтобы такого не произошло внедрять необходимо этапами, на готовом проекте и штатных исполнителях и уже после обкатки выводить вовне.
Возникла как попытка разобраться какая схема работы будет наиболее удобной для… исполнителей.
А исполнителей спрашивали? Как минимум, не всем программистам нравятся чётко расписанные задачи, где даже интерфейсы и библиотеки без твоего участия выбрали. С другой стороны, не всем нравится только задачи декомпозировать и выбирать интерфейсы и библиотеки.
Ну, если о конвейере типовых задач говорить, а не об инженерном творчестве...
Не сказал бы с одной стороны, а, с другой, формализация и декомпозиция могут отнять больше ресурсов чем реализация без таковых.
формализация и декомпозиция могут отнять больше ресурсов чем реализация без таковых
Это нормально. Формализации и декомпозиция в данном случае предназначены для атомизации задач и снижения их связности с базой знаний и другими модулями проекта. Вхождение в такую задачу будет низким, время выполнения минимальным, издержки на рефакторинг и тех долг снизятся, по сути это инвестиции в будущее проекта.
Это нормально.
А если заказчику нужно ехать, а не шашечки?
по сути это инвестиции в будущее проекта.
Которые
а) предполагают более дорогую, и самое неприятное, более длительную разработку.
б) увеличивают срок окупаемости проекта
в) сами по себе с высокой долей вероятности не окупятся никогда. В том плане, что экономия бюджета, полученная от увеличения эффективности разработки вследствие подробного документирования, формализации/декомпозиции задач, будет меньше (а для некрупных проектов — значительно меньше), чем потери на реализацию этих действий.
прошло полтора года. не могли бы Вы поделиться — какие результаты и насколько сильно изменился процесс на практике?
Новый формат отдела разработки ПО