Chief Software Architect в Sigma Software
  • 12 ошибок при построении архитектуры ПО

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

  • Как подходить к тестовым заданиям: советы от тех, кто их проверяет

    Конечно, Вы правы, нельзя быть спецом во всем. Мне кажется T-Shaped модель хорошо описывает ожидаемое компаниями: medium.com/...​haped-people-e8706198e437
    Суть в том, чтоб каждый был специалистом в какой-то своей области, но при этом имел обзорные знания в других/смежних областях. Такие обзорные знания делают взаимодействие различных специалистов эффективными.

  • Как подходить к тестовым заданиям: советы от тех, кто их проверяет

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

  • Как подходить к тестовым заданиям: советы от тех, кто их проверяет

    Ситуация на рынке такова, что компаниям нужно намного больше специалистов, чем возможно найти и нанять. В таких условиях мы не можем себе позволить отказаться от какого-то способа поиска и привлечения, даже от самого неэффективного :).
    Но если вернуться к теме тестовых заданий, мы на самом деле даем их совсем не часто, думаю и 5% не насобирается. А кандидатам, на которых мы вышли через нетворкинг, возможно и вообще никогда не давали, ведь нетворкинг означает, что у нас уже есть какая-то информация от тех людей, которые с кандидатом работали, а это обычно более информативно, чем ТЗ.
    А касательно «песчинки в нашей воронке» :), Вы зря так говорите, мы очень ценим и уважаем всех наших кандидатов, приходите к нам, сами оцените. Более точной будет аналогия драгоценного камня в воронке/сите с песком, и наша задача не упустить вас не набрав при этом поуши песка.

    Поддержал: Max Shnurenok
  • Как подходить к тестовым заданиям: советы от тех, кто их проверяет

    Вадим, мне кажется Вы исходите из позиции, что все приходящие кандидаты — это адекватные люди.На деле же ситуация совершенно обратная — 95% резюме и заявок, которые мы получаем и должны рассмотреть, имеют слабую корреляцию с тем, чем мы занимаемся и кого ищем. Сотни писем в день прилетает от людей, которые не всегда вообще понимают что такое ИТ, от людей не из нашей отрасли, от начинающих специалистов, которым впарили коммерческий курс «стань программистом за месяц», и вот они его закончили и теперь готовы к работе :). Многим так же не повезло работать в компаниях, в которых знают как грамотно работать, в компаниях с процессами, с «разделением труда» да и просто с грамотными специалистами. И вот вроде резюме не пустое, и опыт практический есть, но умеет только «на коленке» что-то сделать.
    Если бы приходили только люди которые здесь оставляют коменты, мы бы с радостью брали всех за половину собеседования, но увы, реалии заставляют нас тратить сотни часов работы на то, чтоб отсеять всех нерелевантных как можно раньше, не тратя на это время технических специалистов. Думаю Вам бы тоже не понравилось тратить время на собеседование десятков людей, из которых 2-3 имеют какое-то попадание, Вы были бы первым, кто сказал бы «кого вы мне присылаете? Делайте отбор, не присылайте всех подряд, зачем я трачу на них свое время?»

  • Как подходить к тестовым заданиям: советы от тех, кто их проверяет

    Разделение труда стало популярным в эпоху индустриализации. Суть в повышении эффективности и взаимозаменяемости, т.е. чем больше разделение труда, тем менее важно какой именно конкретный человек выполняет работу, тем легче нового обучить работе, и следовательно тем более такой чекловек легко заменим. Яркий пример — это работник на конвеере завода, работа которого может заключаться в том, чтоб прикручивать правую дверь к автомобилю, изо дня в день. Недостатоком разделения труда являются монотонность, ощущение бессмысленности своей работы в виду того, что ты не видишь общей картины и не понимаешь свой вклад в общее дело или считаешь его ничтожным. Исследования говорят, что наличие purpose для работников умственного труда является одним из трех основных мотиваторов: www.youtube.com/watch?v=u6XAPnuFjJc, следовательно сделай ты в ИТ конвеер, в нем люди не будут работать.
    Как по мне, то выходит, что для «галер» напротив выгодно делать разделение труда, не полагаться на конкретных людей, а делать их винтиками в машине, которых было бы проще обучить и заменить. Но увы, схема завода просто не работает для нас, так что дело совсем не в том, что компании хотят всех отэксплуатировать, а в том, что в нашей деятельности по другому работает плохо.

  • Как подходить к тестовым заданиям: советы от тех, кто их проверяет

    Дмитрий, я и не говорил, что вы утверждаете, что

    «Без четкого ТЗ ничего не делаю»

    :). По моему мнению, в этой части статьи автор хорошо дает ответ на вопросы вида «А как же BA? Почему не разделить обязанности? Так ли уж необходимо и разработчику в это вникать?».
    P.S.
    Скопировал релевантный кусок, чтоб было удобнее читать дискуссию.

  • Как подходить к тестовым заданиям: советы от тех, кто их проверяет

    www.linkedin.com/...​development-jesse-watson
    But If Someone Else Knows the Business, Why Can’t They Can’t They Just Give Me a Spec?

    The greatest misconception about software development is that it is a separable discipline from deep analysis of the business problem. We think all we need is an analyst who understands the business problem, a developer who knows how to code, then they can email a few notes or a specification. “Good to go”, right?

    Not so much. At the outset, a business problem might appear simple, or only somewhat complex. You might think you have a handle on all the caveats and corner cases. But the average person who hasn’t programmed extensively doesn’t appreciate the level of detail and explicitness that computers require to do absolutely anything. Every behavior must be dictated with excruciating specificity. And your plan for how users will interact with the system will likely get thrown out and redrawn from scratch dozens of times before you have a minimum viable product.

    No matter how good you believe you are at envisioning the details, or how sound you believe your logic is, when things get complex, you’ll find yourself quickly humbled by the users keeping you honest about what they want, and the computer keeping you honest about the cost of developing it. You’ll find out you don’t understand the business logic “at depth” until you’ve tried building an application to solve it.

    But even that doesn’t touch on the biggest challenge of software development.

    In my experience, if you added them all up, most of the miles logged on any software project (the majority of the design effort, coding hours, testing, bug fixes) are not spent dealing with technology-related issues or the business logic, as such.

    Most of the time is spent thinking and communicating about a virtually endless number of micro-problems that seemingly emerge out of nowhere, and constitute the real territory between the technology and the business problem. Part of traversing this landscape of micro-problems is inventing, communicating, and internalizing a plethora of named and unnamed abstractions. It is the only way to break down the complexity so you can grapple with it.

  • Как подходить к тестовым заданиям: советы от тех, кто их проверяет

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

  • О менталитете датских IT-шников — рассказ украинского разработчика

    Но могут участвовать в их решении :).

  • О менталитете датских IT-шников — рассказ украинского разработчика

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

  • О менталитете датских IT-шников — рассказ украинского разработчика

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

    Поддержал: Max Shnurenok
  • О менталитете датских IT-шников — рассказ украинского разработчика

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

  • О менталитете датских IT-шников — рассказ украинского разработчика

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

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

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

  • О менталитете датских IT-шников — рассказ украинского разработчика

    Александр, спасибо за статью! Согласен с комментариями, в которых пишут, что мы тоже не стоим на месте, наши офисы все чаще и чаще выглядят вдохновляюще, а не уныло, ну а значительная часть комментариев только подтверждает описанные в статье явления :). Не так уж много людей в ИТ любят свое ремесло, горят тем, чтоб делать что-то классное, приносить пользу и т.п. Конечно, люди работают чтоб заработать, но можно просто зарабатывать для себя и плевать на все остальное, а можно зарабатывать и в то же время своей работой приносить как можно больше пользы. Можно любить свою работу :). Можно сравнивать компании по кол-ву дней отпуска или размеру компенсации спортзала, а можно интересоваться чем компания занимается, что компания и люди в ней считают важным в этой жизни и своей работе, какие проекты они делают и хочу ли это делать я. Но «ценности — это все булщит, созданный компаниями, чтоб вешать лапшу сотрудникам и меньше им платить» же ))).

  • World of tasks, или Куда разработчикам прикладывать Product thinking

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

  • World of tasks, или Куда разработчикам прикладывать Product thinking

    Если ты не знаешь, как твои усилия влияют на конечный результат, то для тебя твоя работа становится в некотором смысле бессмысленной. До индустриализации люди занимались ремеслом, они понимали что они делают и для чего, они любили свое дело, учили ему своих детей, они гордились тем, кем были.
    Индустриализация заменила персоналии на процессы, и для повышения эффективности процессы разбили на ряд активностей — конвеер. Работник в таком конвеере не делает что-то значимое, к нему поступает деталь с дыркой, в которую нужно вкрутить болтик, и как только он это сделает за ней приезжает следующая точно такая же деталь. В такой ситуации сложно говорить о пользе, которую приносишь, ты понимаешь, что конкретно от тебя ничего не зависит, не выйдешь ты завтра на работу и болтики будет вкручивать другой Вася. Остается разве что думать о том, что ты просто зарабатываешь деньги, вот и весь смысл работы.
    В ИТ, мне кажется, ситуация не определенная и многое зависит от конкретных людей. Можно видеть себя частью конвеера и говорить «вот сюда поступают тасочки, я их делаю, остальное меня не колышит, хотите чтоб я делал что-то еще, добавляйте денежек», а можно заниматься ремеслом — любимым делом, «делать лучшие кольчуги или вилы в округе», удобные для пользователей, видеть и понимать как они делают жизнь воинов или мирных жителей проще, лучше, гордится этим.
    Разговор не о том, что от ИТшников кто-то хотчет бОльшего за те же деньги, а о том, как мы сами воспринимаем нашу работу, как мы хотим ее воспринимать — как бессмысленный конвеер от которого не получаешь никакого удовольствия или как ремесло и любимое занятие, осмысленное занятие, с видимым результатом и влиянием на мир.
    Вот пример отношения, о котором я говорю:
    «Innovation is what drives the world forward. It’s what makes the world a better place and the reality is that every era has it’s defining technology. In 1800, it was steam power. In 1880, electricity. In 1925, the internal combustion engine. Today, it’s evident that the defining technology is IT. It’s also evident that innovators in an era’s defining technology are the people who create the future. Do you ever feel like you’re just writing one more piece of code or testing one more app or going to one more meeting? You shouldn’t feel that way. You work in IT. We are the people who drive the world forward. The truth, and I believe this with all of my heart, the truth is this. We work in the most important profession in the world». David Chappell

    Поддержал: Владимир Чернышев
  • World of tasks, или Куда разработчикам прикладывать Product thinking

    Пока этот скил в дефиците, специалисты им обладающие безусловно получают больше. Когда наберется критическая масса спецалистов с этим скилом — он станет нормой и те, кто не овладел — потеряют в ценности.
    Все разговоры сводятся к +300 ). Я не говорю, что нужно работать бесплатно, я говорю, что цивилизация развивается, мир развивается и меняется профиль востребованных услуг. Можно еще какое-то время продолжать делать то, что делал вчера, но прогресс не остановить, поезд все равно уйдет. А можно развиваться, идти в ногу с рынком и повышать профессионализм и авторитет не только личный, но и нашей страны на мировом рынке. Ну и конечно продавать это преимущество и зарабатывать на нем.

    Поддержал: Oleksandr Tamilin
  • World of tasks, или Куда разработчикам прикладывать Product thinking

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

    работу Сизифа

    .
    Часто вижу в коментах мысли вида «у нас мало продуктов, нам нужно больше своих продуктов, все продукты в кремниевой долине». Видели как американцы работают? Я не говорю про владельцев бизнеса, про всех, кто работает в команде — они искренне переживают и паряться о своем продукте. Для нас же это выглядит дикостью, у нас лейтмотив обычно «чего я должен переживать о его продукте, вот пусть он мне даст акции, тогда посмотрим» и «корпоративная культура, ценности, цели — это все менеджерский булщит. Чего это я должен с коллегами разговаривать или поддерживать беседу, я не нанимался „лучшим другом“, я пришел сюда набирать код, все остальное меня не колышыт. Лучше накиньте 300 баксов, вместо этих ваших культур и тим билдингов». А рынок услуг тоже развивается, клиенты приходят за доменной экспертизой, за консультациями и советами не чисто по технологиям, а по тому, как приносить больше велью, как добиться бОльшего результата.
    — Вот у нас есть классные разработчики
    — Это хорошо, а вы умеете делать Active Safety системы?
    — Эээ, ну нам все равно какую систему делать, что скажете, то они и сделают
    — Та нет, пойдем искать тех кто умеет.

  • Без каких софт скиллов не дорасти до Senior- и Lead-позиций: о личностных качествах

    Мне кажется, что задачи, которые выдают/доверяют специалисту имеют корреляцию с тем, каким опытом и навыками он обладает, какие задачи способен делать. Если у вас есть работник, который может набирать код в ИДЕ, то что другого вы сможете ему отдать/доверить? Если же этот работник желает делать другого рода работу (решать бизнес или технически сложные задачи), и он не просто желает, а как-то готовится к этому (учится, развивает скилы и т.п.) — то конечно вы с радостью используете его на следующей такой задаче.
    Наш мир, технологии, наша отрасль постоянно развиваются. Это значит, что мы не решаем каждый день однажды решенные задачи, мы используем готовые решения или автоматизируем их, а вместо них перед нами встают все новые и сложные проблемы.

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

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

← Сtrl 1234 Ctrl →