КОЛОНКИ · 09 февраля 2018, 09:41 · Отдел информации dev.by
«Компании сами порождают вечных мидлов». Как Scrum убивает креативность

Задумайтесь на минутку, когда в последний раз вы сделали на работе нечто, что было бы не стыдно показать маме? Чем вы могли бы похвастаться друзьям за кружкой пива в баре? Белорусский iOS-разработчик Андрей Малыгин рассуждает о том, что убивает вдохновение и креативность в ИТ-специалистах — и причём здесь scrum.

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

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

Давайте подумаем, почему так происходит и что с этим делать.

Mr Tom, Flickr

Я предполагаю, что эти проблемы будут волновать немногих. Текущий порядок вещей прекрасно подходит для того, чем занимается большинство белорусских ИТ-компаний, а именно: выжигать часы и выставлять за это счета клиентам. Именно поэтому у нас так распространён scrum, ведь он буквально создан для таких целей. Процесс абсолютно прозрачен: заказчик является неотъемлемой частью команды и видит, что происходит. Демо в конце каждого спринта, еженедельные отчёты менеджеров по проекту призваны показать, в каком состоянии находится продукт. Также scrum снимает львиную долю ответственности: все изменения, неизбежно вносимые заказчиком, оправдывают сдвиг сроков сдачи. А значит, больше часов, которые можно выставить в чеке. Зачем что-то менять, если это работает?

Вот к чему я клоню: вся эта ситуация приводит к последовательному искоренению вовлечённости в создание продукта и креативности. Что порождает вечных мидлов.

Итак, что обе стороны могут с этим сделать?

Мотивация

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

Cheryl Colan, Flickr

Безусловно, адекватная оплата труда — неотъемлемая часть мотивированности человека, однако не единственная. В свой книге «Драйв: удивительная правда о том, что нас мотивирует» Дэниел Пинк приводит аргументы в пользу того, что любая работа, требующая хотя бы минимальной заинтересованности, не может полностью мотивироваться внешней выгодой. В этом случае, для мотивации необходимы и  внутренние причины, а именно:

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

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

— Цель. Люди хотя делать важные вещи, а не бессмысленную мелкую ерунду. Если они знают, что это действительно важно и окажет заметное влияние, человек будет более сосредоточенным и вовлечённым.

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

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

Flickr

Вы не задумывались, почему большинство резюме выглядит совершенно одинаково: длинный список проектов, где роль самого человека весьма расплывчата? Но ведь на собеседовании как раз спрашивают: а что сделал именно ты. И оказывается, что ответ «работал в команде и закрывал таски согласно плану» не подходит.

Креативность

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

Многие люди уверены в том, что невозможно приобрести талант создания новых идей и свежих решений. Однако это не так. В свой книге «Техника генерации идей» Джеймс Янг предлагает 5-ступенчатый процесс обретения навыка креативности.

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

  • Шаг первый. Собрать сырой материал
  • Шаг второй. Обработка материала
  • Шаг третий. Подсознательная обработка
  • Шаг четвёртый. Момент озарения
  • И, наконец, пятый шаг. Соотнесение идеи с реальностью

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

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

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

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

Что с этим делать?

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

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

Соберитесь вместе с друзьями или коллегами, придумайте что-то действительно сложное и начните осуществлять. Пусть это будет медленно. Пусть вы набьёте много шишек. Пусть иногда будет страшно. Но это даст вам бесценный опыт и поможет завести новые знакомства. Работа над своим проектом поможет не только приобрести новые навыки, что полезно для карьеры, но и поднимет уровень мотивации к жизни в целом. Скорее всего, вы не заработаете свой миллион долларов и Цукерберг вам не позвонит, но не совершая таких попыток, вы лишаете себя всех возможностей полностью. Найдите что-то интересное в open source. Может быть, ваше любимое приложение или сайт выложены в открытый доступ. Просто изучая работы профессионалов в своей области, вы получите множество новых идей.

Со стороны компаний стоит не на словах, а на деле начать заботится о развитии способностей своих сотрудников.

Стоит начать нанимать людей в команду, а не на проект. Политика «незаменимых нет» не только унизительна, но и отталкивает новых кандидатов. Даже маленькие компании могут выделять время и скромные бюджеты на проведение хакатонов, конференций и просто изучение чего-то нового в рабочее время. Не говоря уже о крупных корпорациях, которые могут спонсировать успешных ребят.

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

 

Читайте также: Как продвигать компанию и искать разработчиков при помощи open source. Опыт белорусов из топа GitHub

Источник: dev.by
Нашли в тексте ошибку — выделите её и нажмите Ctrl+Enter.
Новые комментарии
Европа была позади в IT а сейчас будет отставать ещё сильнее. ИМХО, это не просто мешает развивать бизнес на основе данных но и налагает особые условия на организацию системы, т.к. требует отдельной проработки и затрат. Новые продукты начнут выходить на рынок европы с задержкой, некоторые не будут вообще выходить. Но что они защищают я не пойму, информацию можно использовать как во благо так и во вред. Логично контролировать использование информации а не её наличие. Логично не хочешь передавать данные не используй продукт, альтернатив много. А.. они же не такие удобные, интересно почему? Может просто они не получают достаточно прибыли чтобы кормить армию специалистов которые все сделают идеально, почему? Я лично facebook не использую и живу отлично, не нравится что google о вас собирает данные тогда стоит вернуться в эпоху каталогов, и подумать что лучше иметь отличный бесплатый продукт но поделиться инфой для формирования рекламы или старый добрый каталог? Права на забвение я вообще не понимаю, если информация правдивая то почему она должна исчезать из различных источников, получается интересны отдельного человека ставятся в приоритете интересам общества - т.е. доступу к знаниям о происходящем.
Wistful
27.05.2018 в 23:45
Юридический язык — это не C++. Как белорусские компании подготовились к GDPR

Обсуждение

Missing
+9

Почему именно Scrum убивает ? Если все-все решения принимаются дядями где-то далеко, то что есть Скрам, что нет его - один фиг.

72082ea01bc2e51b43f8e84c0aa66bb8?1398977499
+3

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

Missing-male
+8

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

B993ebcd20d5803b01e1810b59038c5b?1527371885
+5

Agile и Scrum - это способ заработать денег проводя курсы и продавая сертификаты :-)

Missing

а Waterfall это способ заработать денег проводя курсы и продавая сертификаты?

63637f4ec5ea136f9d17ce151501368e?1401052531
+6

waterfall это водопад.

Missing
+3

а scrum - свалка

72082ea01bc2e51b43f8e84c0aa66bb8?1398977499
+8

Что говорит статья: хочешь креативить - не будь программистом, а будь заказчиком.

Missing-male
+2

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

С другой стороны, в "творческих проектах" обычно все процессы поставлены через одно место (или отсутствуют вовсе) и напрочь отсутствует дисциплина написания кода/документации. Все стараются делать всё как можно быстрее и так как им кажется правильным. Такие проекты очень быстро становятся неподдерживаемыми и заговнокоженными всякими экспериментами. Появляются незаменимые разработчики (в плохом смысле - они делают такой код, который понятен только им). Поэтому очень важно следить за внутренней культурой в команде. Жёстко дрючить всех без исключения на код ревью: по стилю, за каждый лишний пробел или пропущенный const. За нарушение принципов SOLID/RAII и т.п. За злоупотребление KISS. И т.п.

Missing
+5

Ага. На эксперимент никто не сможет выделять время бесконечно. Наступает момент, когда "хватит экспериментировать, надо уже результат показать". И вот тут иногда получается жёсткая жесть. Сидишь и думаешь потом, нафига были все эти эксперименты :)

Missing-male
+4

Чтобы такого не было - нужен нормальный техлид и нормальный roadmap в котором заложено время на исследования.

Missing
+4

> Все стараются делать всё как можно быстрее и так как им кажется правильным

Только это и работает. Много вы видели проектов которые развивались правильно с процессами, code review и 100%м тест coverage с самого начала?

Чисто из опыта - об этом начинают заботиться когда в команде под 50 человек и многомиллионная годовая выручка. Если не взлетит - не всё ли равно, выкидывать корявый или красивый код.

Missing-male
+5

Видел много перспективных проектов (в белорусском геймдеве, например), которые не взлетели из-за тухлых процессов. Тут надо понимать, что забивая болт на качество кода заказчик рискует. Да, с одной стороны идёт определённая экономия средств. Но с другой, повышается вероятность появления багов, которые из-за плохого качества кода будет очень дорого пофиксить. И такие баги могут очень сильно ударить по доходности проекта. Вспомните то же диаблу, когда там количество бабла у игроков перестало влазить в int32 и привело к необходимости отката базы. Геймеры негодовали, у компании - огромные убытки.

Так же сам лично работал на проекте (в Vizor) с правильными процессами, код ревью и т.п. Нужно ведь понимать, что на том же прототипировании сто лет не нужны юнит тесты. Все подходы (тот же scrum/kanban) должны использоваться с головой, а не бездумно догматически орать "спринт, продакшн, код ревью, рефакторинг, стори поинты".

Чисто из опыта - об этом заботятся нормальные тим лиды в нормальных командах, независимо от размера проекта и даты его старта.

Missing

> нормальные тим лиды

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

Missing-male

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

Missing
+3

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

> Все, кто когда-либо пробовал протащить в спринт минимальный рефакторинг или экспериментальный новый подход, прекрасно меня поймут.

А вот на это и вовсе бывает нет времени и постоянные споры, особенно с тестерами.

Missing-male
+7

фундаментально всё печальнее, гораздо

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

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

Missing-male

Это в Беларуси так, так как в плане айти это страна чистого аутсорса. В странах-заказчиках с этим всё гораздо лучше

Missing
+4

Наверное, автор статьи не совсем понимает принципы Scrum. Как раз таки этот фреймворк разрабатывался разработчиками и направлен на то, чтобы именно скрам-команда была самоорганизованной и самодостаточной. Как это работает на практике? Да очень просто: product owner (сам или от лица заказчиков) говорит, что он хочет получить, а Dev-команда говорит, как они это могут сделать, будь это 1 вариант или 5 - у каждого должно быть обоснование, риски и оценка. Иными словами, команда разработчиков решает, что нужно сделать, чтобы достичь поставленной цели, а никак не заказчик. А то, о чем говорит автор, больше похоже на waterfall, когда уже написали ТЗ на уровне аналитиков, согласовали его с менеджментом, получили оценку от архитектора или тим-лида и потом все это вбрасывают команде разработки. Может, проблема в том, что в компании автора статьи применяется waterfall, который называется модным словом "Scrum"? :)

Missing-male
+6

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

Missing
+1

ТЗ в runtime запросто приводит к говнокоду. В принципе многое зависит от уровня.

Missing-male
+2

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

Missing
+3

Рак лебедь щука:) Без технического видения далеко не уедешь.

Missing
+2

Китайцы ж давно решили проблему - девушки модельной внешности для "парного программирования" ;)

Picture_2702?1356409883
+2

Угу, сидит рядом и периодически с южным акцентом и жестикуляцией восклицает: "Вахъ, какой красивый функция написал?! Ты мой герой!" :)

Picture_432?1356409809
+8

Scrum притянут за уши для красивого заголовка.

Вторая часть статьи правильная.

Делайте продукты.

Missing
+1

Поправочка: делайте СВОИ продукты :)

B22cf3b2327970a0352447b567a4841a?1527232155
+18

Поправочка к поправочке: САМИ делайте СВОИ продукты ;)

Missing-male
+2

в современных реалиях норм продукт это человеко-век по эстимэйтам

Missing-male
+1

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

F66e33f1b11b0312e10c2ed1a9e39188?1522757268
Sergey Bodrov
– инженер-программист в Новатех

+8

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

А если в душе лишь осознание собственной исключительности, то никакие советы не помогут.

Missing
-1

это нормально http://www.hr-portal.ru/article/4-tipa-sotrudnikov тут HR уже поделили сотрудников на: пионеров, драйеров, стражей и интеграторов:)

Missing
+3

Скрам, конечно, не помешает а вот начальник, да. Уволиться придется.

Missing
+3

В статье очень правильно обозначена проблема, но она не связана напрямую со SCRUM или любой другой методологией. В целом это вопрос организации производства. На определенном этапе вопрос эффективности заставляет создавать что-то наподобие конвейера. Его еще Чаплин высмеивал в фильме "Новые времена". И не важно прикручиваешь ты дверцу авто или API. Принцип тот же. Посыл статьи - пытайтесь попасть в ОКБ (опытно-конструкторское бюро), либо организовать свое, для персонального потребления и развития. К счастью в ИТ, отличие от материального производства, это сделать легче.

Picture_2702?1356409883
+1

Производство, фундаментально, состоит из двух процессов: проектирование прототипа (один раз) и копирование прототипа (много раз). "Прикручивание дверцы" это как раз копирование исходного прототипа разработанного в ОКБ. И стоимость этого же копирования в IT близка вообще-то нулю. То есть, с точки зрения завода, на котором прикручивают дверцы к авто, вся работа в IT это разработка самого первого прототипа == работа в ОКБ.

Только вот ОКБ и проекты бывают разные... чем больше/масштабней проект, тем больше по размеру надо ОКБ и тем больше бюрократии и элементов конвейера. А как уже будет организована данная бюрократия, по скраму, аджайл или водопаду пофигу. Со всеми вытекающими.

Missing
+2

в тему https://xpinjection.com/articles/shu-ha-ri-for-scrumoholics/ «Сухари» для Scrum-оголиков

Вот некоторые характерные черты:

Он свято верит в то, что Agile и Scrum – это слова синонимы. Отождествляя эти понятия, любое отклонение от Scrum истолковывается как анти-Agile

Он считает Scrum идеальной методологией, которая подходит абсолютно для всех проектов. Если Scrum не работает для вашего проекта, то вы просто неправильно делаете Scrum

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

Он категорически относится ко всему традиционному и не связанному с Agile, называя это одним общим термином Waterfall

Он считает Scrum больше чем просто методологией, скорее философией или ядром мировоззрения

Missing
+1

не читал но осуждаю

Missing
+3

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

Это похоже на какую то секту.

А это лишь один из возможных способов управления проектом, и далеко не ко всем типам проектов

эта метода вообще говоря применима.

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

то, что управления нет вовсе, или управленец просто напросто лажает, не осознавая приоритетов.

Так что так сильно нажимать именно на управление проектом, да притом именно только на такое

и никакое другое - это, извините, лишнее.

Это просто от тотального недостатка опыта и отсутствия собственных идей и мыслей.

Какой то карго культ. Будем повторят вот эти действия и манна сама с неба свалится.

Missing-male
Mitri
– Капитан в ИП

+2

Тут нужно различать - продуктовая контора или оутсорсовая. Поскольку работал и там и там то по поводу продуктовой конторы:

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

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

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

2. Оутсорсовая контора.

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

Как-то так.

Missing
+1

> Кто помнит лихи 2000-е тот подтвердит.

2000-е помню. А что за элементы лихости были в них? (Можно какую-нибудь историю или пример? Действительно интересно.)

Missing-male
Mitri
– Капитан в ИП

-1

Работали без опыта и процессов не было по началу. Дикое программирование. Я именно про начало. Про 2000-й год и последующие. Помню эти наивные попытки написать ТЗ которое раз и на полгода без изменений. Багтрекер в экселе на расшаренной папке... Его синхронизация с заказчиком через емайл )))

Missing
+1

И что с тех пор собственно изменилось?

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

и качественно - нет никакой разницы.

Это же всё всего лишь вспомогательные инструменты и ничего более.

Они что-то может быть и улучшают, но принципиально ничего не меняется,

может быть даже наоборот - отнимаю время на ведение логов, репортинг и т.д.

Это как у монтажника другая отвёртка, или аккумуляторы другие в шуруповёрте.

Сам монтажник лучше от этого не становится, ну не становится от нового аккумулятора

в 2 раза более шустрым сам монтажник.

Если он разгильдяй - разгильдяем и останется, как крутил 2 шурупа там, где нужно 4 так и будет крутить.

Если был алкашом, который может забухать на месяц - даже с новой (мега крутой и соответствующей всем мегастандартам) отвёрткой

так и будет бухать месяцами.

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

Давайте рассмотрим ЛЮБОЙ опен соурсный проект, который держится на энтузиастах (и пусть даже немного спонсорстве).

Вот например linux.

Огромный, с 90 годов (с картинок в букваре для вас, наверное) огромный и очень успешный проект.

И никакого скрама.

Если у вас 6 человек на проекте, вы их видите и слышите каждую минуту - зачем вам формальное

ведение такслогов. Они же точно так же могут и будут вестись формально. Просто туда

будут репортить ежесуточно "по 8 часов" и всё.

Missing-male
Mitri
– Капитан в ИП

+1

Ой, ой. Сколько пафоса. Посмотрел бы я на вас и заказчика, отними у вас сайт с багтрекером, который можно открыть хоть из дома, хоть с работы и ждать пока придет емайл с обновленными статусами.

Missing
+1

Простите, зачем открывать сайт с баг-трекером из дома?

Missing
+3

Ничего принципиально нового с тех пор не появилось. Были процессы (Rational Unified Process), был UML и тулы для работы с ним, были нормальные багтрекеры в ассортименте, был MS Project для планирования и ведения проекта, были тулы для Continuos Integration, были version control systems - было абсолютно все для полноценной работы над проектом на всех итерациях.

Я не минусовал, но и согласиться с такой историей тоже не могу.

Missing
+1

На момент двухтысячных да были, не такие навороченные как сейчас, но уже были.

В девяностые даже система контроля версий была проблемой.

Но как уже писал - это просто второстепенные, вспомогательные инструменты.

Missing
+1

лет через 20 буду детям рассказывать "А вот помню в лихие дветысясидвассатые, когда биткоин упал а риппл не поднялся... "

Missing
+1

Нет никакой разницы с точки зрения управления проектом, продуктовая у вас компания или аутсорс.

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

Бывает, однако, так, что даже на аутсорсе этого заказчика по факту нет.

Если заказчику не интересно, как идёт проект, его детали - нет никакой возможности

его заставить вникать в это. Вы можете топить его хоть ежедневными отчётами - этот

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

проект в срок, или не так как нравится заказчику нарисовали кнопку.

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

полномочия.

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

Вопрос как её организовать зависит и от заказчика и от разработчика,

и это не должно подменяться модными словами которые на деле

превратятся в потерю времени коллектива на некие сектантские ритуалы.

А в 50-60% случаев это именно так.

Missing-male

Почему у большинства приличных строителей получается разрабатывать и строить с первого раза и с косметическими багами?

Missing

Ну и чушь же!

Missing-male

Статья сама типичный scram - всё в кучу, перемешали, пару красивых идей и вроде как вышел продукт... Всегда и везде на любом производстве (а что это иное как не производство IT продуктов) будут те кто изобретает новые модели и те кто просто крутит гайки на конвейере. И для продукта важны и те и эти.

Missing-male
+1

Именно поэтому уехал из Беларуси - 90% проектов скучные и однотипные. Всё самое унылое скидывают на аутсорс туда, поэтому в белорусском айти и не нужны сеньоры и креативщики - нужны средненькие детальки, желательно максимально заменяемые

Missing

Стесняюсь спросить когда именно вы уехали?

Например за последние 10 лет в Минском айти зарплаты вырасли в разы (примерно в 3 раза).

А число продуктовых компаний в минске выросло по ощущениями на порядок (читай в 10 раз).

Даже если соотношение не изменилось (90% проектов отстой), то это не важно.

Выбор уже откровенно есть и приличный. Вам же нужна одна работа, а не 100 или чтобы каждая нравилась.


Авторизуйтесь, чтобы оставлять комментарии

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси