• Разработчики встраиваемых систем не умеют программировать
    +2
    Я вроде качал тесты на SQLite и мне помнится, что их было на 2 порядка меньше.
    92 миллиона строк — это с дампами баз для нагрузочного тестирования?
  • Из Basecamp уволилось больше трети сотрудников — они недовольны «аполитичностью» компании
    +1
    Скорее ушли те, кто саму постановку вопроса «не нравится — можете уходить» счел для себя неприемлемой.

    Это как в том анекдоте, когда полицейский остановил машину и отоварил дубинкой сначала водителя, а потом пассажира.
    Пассажир:
    -А меня-то за что?
    Полицейский:
    — Чтобы не думал «попробовал бы он так со мной поступить».
  • Из Basecamp уволилось больше трети сотрудников — они недовольны «аполитичностью» компании
    0
    Руководство компании открыто заявило об изменении корпоративной культуры.
    Причем, заявление гораздо шире, чем запрет на обсуждении «политики» в рабочих чатах.
    Они выразили несогласие с этими изменениями.
    Придумывать ничего не надо.
  • Из Basecamp уволилось больше трети сотрудников — они недовольны «аполитичностью» компании
    –1
    И за что человека заминусовали?
    Я мечтаю о временах, когда в России на заявление руководства компании «кому не нравится — можете уйти» треть сотрудников встанет и уйдет… А еще лучше — все встанут и уйдут.

    Кстати, в заявлении Джейсона Фрида было несколько пунктов об изменении корпоративной культуры в целом, включая процесс оценки сотрудников и схему принятия решений. Почему все привязались к «полите» в корпоративных чатах?
  • Как мы свою helpdesk-систему пилили
    0
    Вы же свои расчеты не привели…
    Если Вы платили за helpdesk по 10 тыс. руб. в месяц на человека, то это сомнительный повод писать свое решение.
    Про то, что количество инженеров поддержки удалось сократить в полтора раза, Вы тоже не написали.
  • Опуститься до уровня руководителя?
    0
    С моей точки зрения, при решении бизнес задач, основной критерием изящества является оптимальность решения по сложности и трудоемкости поставленной задаче.
    В книге про тестирование в гугле про это хорошо написано.
    Когда изначально проект развивается как старт-ап, с минимальными требованиями к процессу разработки. И если в нем видят потенциал, начинают инвестировать в качество.
    Это и есть управление качеством.
  • Опуститься до уровня руководителя?
    0
    Вы не верите в успешность работников, которые старательно работают?

    В успешность работников, которые не могут объяснить, над чем и зачем они работают, я не верю.
    Уж извините.
    Выводы делаются на основании личного опыта.
  • Опуститься до уровня руководителя?
    0
    Очень часто техническим долгом становятся как раз изящные решения, т.к. кроме автора их поддерживать никто не может.
    Опять же, к техническому долгу надо относиться как к долгу или кредитам — занимаем сейчас, отдаем в будущем. Все сводится к контролю на этим самым долгом.
  • Опуститься до уровня руководителя?
    0
    Как вы будете вести диалог в рамках agile процесса?


    Если говорим про scrum, то там есть PBR и планирование спринта.
    Объяснять придется владельцу продукта и всей команде, почему на задачу планируется спринт.
  • Опуститься до уровня руководителя?
    0
    «Целеустремленная» предполагает наличие цели. Если сотрудник фокусируется на только понятных ему целях (посте он не смог объяснить, на что было потрачено время), то это идет в разрез с интересами работодателя.
    Вы вызвали такси, чтобы доехать до аэропорта.
    Где-то в глухом месте таксист вышел и вернулся спустя 2 недели. Сказал, что занимался фундаментальными исследования, но чем они заключались, объяснить не захотел.
    И да, оплачивать эти исследования Вам.
    Есть такое понятие «подпольная разработка», но обычно это небольшая доля времени от проекта.
  • Опуститься до уровня руководителя?
    0
    Overdesign — это не профессионально, т.е. результат недостатка квалификации или понимания задач бизнеса.
  • Опуститься до уровня руководителя?
    0
    Если это предложение для «художников», то название статьи я бы ожидал увидеть «учитесь обосновывать свои совершенные решения» или «хочешь работать художником — устраивайся на позицию художника».
  • Опуститься до уровня руководителя?
    0
    Я предпочитаю, когда диалог ведется при постановке или оценке задачи, т.е. на стадии планирования/проектирования.
    А вот если сначала тратиться 2 недели на работу, а только потом думаем, как это обосновать, то я считаю это чем-то сродни навязанным услугам.
    Если работающее решение требует 2 часа, а изящное 2 недели, то выбор должен быть за владельцем бюджета, а не исполнителем.
  • Опуститься до уровня руководителя?
    0
    Все верно, стратегии есть разные.
    И обычно об этом договариваются на берегу — при приеме на работу.
    Скажем, если Вы пришли в стартап с ограниченным бюджетом, то долгосрочные инвестиции в совершенство кода приведут к банкротству — деньги закончатся раньше, чем продукт выйдет на рынок.
    Если же Вас наняли в R&D отдел компании для инноваций, то там и постановка задач другая.
  • Опуститься до уровня руководителя?
    +1
    Я расцениваю это так, что 3 работодателя оплатили навязанную и бесполезную для них работу. 4-й выиграл в лотерею, но в долгосрочной перспективе может потерять больше, т.к. будет оплачивать другую навязанную и бесполезную для него работу.
    Критерии изящного решения Вы так и не привели. Поэтому не очень понятно, в чем заключался выигрыш.
  • Опуститься до уровня руководителя?
    +1
    Автор до сих пор считает коммерческую разработку ПО полигоном для поиска изящных решений и недоумевает, почему индустрия его в этом не поддерживает.
  • Опуститься до уровня руководителя?
    0
    А есть ли критерии изящества?
    И в какой момент нужно остановиться?
    «Работа над произведением искусства никогда не может быть закончена, а может быть только заброшена.»

    Если 2 недели поиска изящного решения не улучшили качество продукта для пользователя или не принесло ничего для бизнеса, то ROI = 0.
    Кроме сроков менеджеры используют и другие показатели или метрики: качество (удобство пользования, эстетическое восприятие, надёжность), стоимость эксплуатации или владения (производительность, потребление ресурсов масштабируемость), стоимость сопровождения (скорость исправления дефектов, сложность внесения изменений, «хрупкость») и т.п.
    Если изящность не ложится ни на один из них, то в чем его ценность для того, кто оплачивает эту работу?
    Дурацкая притянутая за уши аналогия: я пригласил маляра покрасить стену, а он вместо краскопульта или валика расписал ее беличьей кистью №4. В один цвет, в лучшем случае дотянул по качеству до валика. «Художника может обидеть каждый»?
    Бывают ситуации, когда компании выгодно иметь такого специалиста, если, простите за пошлость, «монетизация» идет через PR (статьи, конференции, олимпиады), обучение коллег, создание атмосферы «избранности» в команде или поддержание ЧСВ у учредителей. Но это какая-то отдельная история.
  • Как мы свою helpdesk-систему пилили
    0
    Как может быть рентабельной «домашняя» разработка достаточно типовой системы для 40 человек?
    Передоложим, что команда в среднем была 4 человека, 3,5 года. Только ФОТ минимум 20 млн. Общие расходы на разработку за это время минимум 30 млн.
    Jira service desk (для примера) 1,5 млн лицензия + 0,75 млн в год поддержка на 50 пользователей. Workflow кастомизируется, статусов можно хоть 15 сделать. Если чего-то не хватает — можно дополнительные плагины купить или заказать. Для интеграции есть API.
    Окупаемость 25-35 лет, а не 3-5. И это при условии, что на поддержку своей системы не будет расходов в будущем. Но я так понимаю, что команда продолжает проедать 10 млн в год.
    С моей точки зрения, из 4-х вариантов: покупка готового, кастомизация готового, заказная разработка и собственная разработка выбрали самый затратный и самый рискованный.
  • Меня перевезли в другую страну и через две недели выставили на мороз — потому что передумали нанимать
    0
    Кстати, от Минска до Смоленска километров 300, до России еще меньше :-)
  • Меня перевезли в другую страну и через две недели выставили на мороз — потому что передумали нанимать
    +4
    Вы устроились в компанию на общих основаниях, Вас уволили на общих основаниях как не прошедшего испытательный срок. Почему Вы ожидаете каких-то преференций?
    Компания совершила ошибку найма, за это предложила компенсацию в размере 2-х недельного оклада. Вы ее приняли.
    Т.е. на тот момент Вас устроили как условия найма, так и расторжения трудового договора.
    Да, бывает, что человека нанимают, и он попадает под волну сокращений на испытательном сроке. Но это же не тот случай.
  • Меня перевезли в другую страну и через две недели выставили на мороз — потому что передумали нанимать
    +4
    Павел, а какую пользу получил работодатель от Ваших страданий? Почему он должен был оценить Ваш героизм?
    90% содержания статьи вообще не лежит в плоскости трудовых отношений.
    Еще раз, я не снимаю ответственности с компании за ошибку найма — но я не считаю, что они Вас «кинули» в юридическом или нравственном плане.
  • Меня перевезли в другую страну и через две недели выставили на мороз — потому что передумали нанимать
    +3
    Компания действительно могла бы взять автора на удаленку на первый месяц испытательного срока, зная что он собирается переезжать издалека.


    Если у компании не выстроены процессы удаленной работы (мы говорим про 2019 год, а не сейчас), то не могла.
    Иметь одного члена команды на удаленке — это очень неудобно, проще не брать вовсе.
    Это резко отличается от ситуации, когда все на удаленке.
    А уж про онбординг в текущей ситуации и вовсе говорить не приходится — это боль, команда тратит усилий и времени больше, скорость адаптации ниже.
  • Меня перевезли в другую страну и через две недели выставили на мороз — потому что передумали нанимать
    0
    Это из личного опыта? Много ли релокейтов у Вас было? Привезти специалиста в цивилизованную страну — это еще тот квест, чтобы было выгодно его «кидать». Ну и обязательства работодателя отличаются от страны к стране.
  • Меня перевезли в другую страну и через две недели выставили на мороз — потому что передумали нанимать
    +7
    Почти полторы тысячи комментариев, даже не знаю что еще можно добавить…
    Я не оправдываю компанию, но исходя из моего опыта, ожидать каких-то грамотных HR процессов в компании до 150 человек особо не приходится. Это как раз та граница, где их начинают выстраивать (еще раз — это про мой опыт, а не конкретную компанию).
    Т.е. компания явно совершила ошибку, наняв на работу Павла, но вышла из ситуации достаточно достойно, выплатив больше, чем должна была по закону.
    Я рекомендую Павлу следующий раз отправлять потенциальным работодателям ссылку на это статью, думаю, что рисков с непрохождением испытательного сроков будет меньше — до этого дело просто не дойдет в тех компаниях, где обращают внимание на soft-skills (в небольших и незрелых больше внимания уделяют именно hard skills).
    1. Название не соответствует действительности, автора ни кто не перевозил — он сам принял решение переехать. Причем, Минск был выбран до того, как он откликнулся на вакансию (я иногда тоже собеседую кандидатов, которые ищут работу именно потому, что решили переехать — я не рассматриваю это как релокацию, т.к. нет такой программы, но риски финансовых потерь с кандидатом обсуждаются).
    2. Павел неправильно понимал термин «испытательный срок» — рассматривал, как срочный договор с возможностью продления (как до этого работал на UpWork).
    3. Похоже, что это его первый опыт работы в штате и в офисе компании, занимающейся разработкой ПО (преподавание и фриланс не способствуют наработке навыков взаимодействия с коллегами).
    4. Так же нет навыков оценки будущих руководителей и коллег на интервью.
    5. Статья про увольнение 18 сотрудников в 2018 году — это не единичный отрицательный отзыв, а статья о сокращение штатов. Там же написано, что увольняли в основном новичков. И если после этого не было вала отрицательных отзывов, компенсация их устроила.
    6. Почитав ответы автора на комментарии, я не удивлен, что его уволили через 2 недели. Я бы на интервью отсеял с большой вероятностью. Soft skills — это навыки, которые можно нарабатывать. Хотя при отсутствии эмпатии это гораздо сложнее.
    7. Павел, я понимаю, что мой комментарий не имеет смыла — есть 2 точки зрения, Ваша и неправильная :-) Моя относится к неправильной :-)

  • Agile без идеализма. Когда и как именно работает гибкий менеджмент. Политэкономический памфлет
    +1
    Как человек, имеющий опыт управления проектами в десятки человеко-лет, я не буду использовать классический водопад даже в случае выигранного тендера. Да, не будет обратной связи от заказчика, но итеративная разработка появилась раньше agile манифеста.

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

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

    Ну и отдельный момент — мотивация команды и наработанная методология.
    Перекраивать их ради одного проекта? Слишком накладно.
    Еще есть тема морального духа и производительности, которая падает драматически в случае потери мотивации.

    Просчёты архитектуры не связаны с методологией.

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

    Для меня Agile не является религией, т.к. я понимаю, какая «магия» скрывается за его эмпирическими методами и ритуалами.
    Поэтому разоблачительную часть памфлета я не считаю убедительной, уж извините.
    С некоторыми утверждениями я вполне согласен.
    В традиционной иерархической организации с директивным управлением внедрить Agile невозможно, нужно каким-то образом менять отношения между сотрудниками и руководством.
  • Agile без идеализма. Когда и как именно работает гибкий менеджмент. Политэкономический памфлет
    0
    Скажите, а как Вы монетизируете написанные на Хабре статьи или комментарии?
  • Agile без идеализма. Когда и как именно работает гибкий менеджмент. Политэкономический памфлет
    0
    Представим себе гипотетическую ситуацию, когда продукт А делают по водопаду, а конкурирующий продукт B по скраму. Оба продукта в итоге имеют один и тот же функционал. Какой продукт обойдётся дешевле по ресурсам? Очевидно, продукт А.

    Нет, это совсем не очевидно.
    Стоимость исправления дефектов разная в зависимости от того, на какой фазе ЖЦ он обнаружен.
    Подход А позволяет выявлять дефекты на ранних стадиях за счет методологии и обратной связи, подход Б нет. Т.е. стоимость устранения архитектурных просчетов может может значительно сказаться на стоимости реализации.
    Нет гарантий, что водопад эффективнее даже при статических требованиях.
  • Agile без идеализма. Когда и как именно работает гибкий менеджмент. Политэкономический памфлет
    +1
    Для меня не важна социализация на хабре.
    Но какое это имеет отношение к обсуждаемому вопросу?
    Комментирую я менее 1% от прочитанных статей.
    Рассматривать современное общество и производственные отношения только с точки зрения экономических отношений… Да, я считаю, что это очень упрощенная модель. Вы не согласны?
    Как в эту модель вписывается гемификация или другие нематериальные способы пощекотать ЧСВ? Почему зону комфорта предпочитают более высокой зарплате?
  • Agile без идеализма. Когда и как именно работает гибкий менеджмент. Политэкономический памфлет
    +1
    Возможно ли ускорить выход продукта, внедрив Agile?

    Нет, невозможно.


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

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

    Agile расцвел, когда пофейлился RUP.
    Стоимость детерменизма в «водопадной» разработке слишком высока для большинства проектов, которые востребованы на рынке.

    Свопы, премиальные фонды — очень плохо работают там, где финансовый результат не зависит напрямую от трудозатрат. Это скорее средство удержания, а не мотивации. И своего рода лотерея (у меня были опционы в 2-х компаниях, миллионов не принесли).

    «В итоге, если продукт разрабатывается под одного потребителя и не будет изменяться, применять Agile, следовать принципам и практикам SOLID, GRASP, DDD, TDD, KISS экономически нецелесообразно.»
    Вот это достаточно сильное упрощение модели.
    ПО, которое не изменяется, очень часто вызывает у пользователей только боль и со временем умирает.
    Т.к. предсказывать будущее мало кто умеет, т.ч. причина для изменений может появится (новые бизнес-процессы, изменение норм, эволюция IT систем и т.п.)
    И базируется утверждение на предпосылке, что заказчик точно знает чего хочет (т.к. пишет техническое задание). А реальные потребности и сценарии использования возникают на этапе внедрения и эксплуатации.

    Возьмите автомобиль времен Маркса и современный. Можно ли было запроектировать так, чтобы потом ничего не менять?
  • Agile без идеализма. Когда и как именно работает гибкий менеджмент. Политэкономический памфлет
    0
    Марксизм об Agile :-) Неожиданно.
    На основании простейшей модели делаются тривиальные выводы.
    Которые справедливы в той же мере, в какой модель отражает реальность.
    Гибкие методологии разработки — это один из способов снижения рисков от неопределенности в ожидаемых результатах и оценке трудозатрат проектов.
    Но Agile совершенно не является инструментом повышения эксплуатации.

    А где Вы доказываете, что сокращение сроков разработки зависит именно от повышения эксплуатации?
    Вы же совершенно верно пишете, что Agile — не делать лишнего, а не делать быстрее.
  • CRM-системы не существуют?
    –2
    Ув. автор, вы решаете не ту задачу.
    Вам была поставлена цель «автоматизировать до зубов».
    Почему-то Вы решили, что она достигается внедрением CRM, и начали тестировать продукты на соответствие определению из Википедии.
    Абстрагируйтесь от калек (CRM, ERP, BPM), подбирайте систему для решения своих задач.
    У Вас маленькая компания, по бюджету может быть только коробочное решение, под которое нужно будет подстраивать свои процессы.
    Любая уникальность в таких масштабах — это просто бардак.
  • Скрам умер. Да здравствует канбан
    0
    Это же вопрос постановки целей команде, а не Scrum.
    Поставили цель «успешно» закрывать спринты — команда этим и занималась.
    Если критерии готовности фичи/релиза допускали просадку качества, то их и нужно было корректировать. Зачем для этого ждать 2 года?
    Я участвовал несколько раз во внедрениях Scrum именно с целью повышения качества. И задача решалась вполне успешно (в «водопаде» большая неопределенность в сроках стабилизации, при давлении по срокам, провалы качества могут быть фатальные).
    И опять же, если количество пользователей выросло в сотни раз, а количество обращений в 2.7, то это очень хороший показатель.
    В результате вместо планомерного развития продукта и движения вперед мы были вынуждены топтаться на месте, разгребая проблемы пользователей.

    В этом тоже нет ничего плохого, если высокая скорость поставки фич позволила захватить или удержать рынок. Своего рода долг, который пришла пора выплачивать.
  • Программист должен решать
    +1
    В целом верно, что на уровне senior карьера только начинается :-)
    Точнее, в Y-модели разделение на технический и менеджерский трек начинается после senior.
    В статье приведены позиции технического трека, названия специфичны для компаний, насколько я знаю.
    И опять же верно, нужен человек, который способен понять потребности бизнеса и предложить сбалансированное техническое решение. В некоторых компаниях такого человека называют архитектором, иногда это роль, иногда это должность, но это senior+ (если бюджет компании позволяет).
    Архитектура — это система компромиссов (уж не помню, где встречал это определение).
  • Пожалуйста, не шумите
    +3
    Автор предлагает вместо видео ходить на курсы, а не читать статьи.
    Точнее проводить такие курсы в качестве источника дополнительного заработка…
    Я соглашусь, что на youtube много всякого шлака, но очные занятия тоже не гарантируют высокое качество преподавания.
  • Пожалуйста, не шумите
    +1
    Я веду индивидуальные курсы параллельно с работой и обеспечиваю людей уверенными знаниями для устройства в IT-компании. Метрику трудоустройства я не собираю, потому что не могу выделить на это время.

    2200 часов на 50 учеников, получается в среднем по 44 часа на одного.
    Судя по материалам на github, за это время ученик успеет пройти введение в программирование, базовый sql и webforms.
    В IT компании после этого возможно и возьмут, но не IT-специалистом.
    Для более-менее нормальной подготовки нужно раз в 10 больше времени.
    Т.е. бюджет в районе 600 тыс. руб.
    Если в youtube искать не просто видео, а именно курсы (со ссылками на конспекты лекций, литературу и задания), то в чем преимущества очных вечерних курсов вообще непонятно.
    Да, качество многих видео очень низкое.
    Но если авторы плохих видео-курсов отправятся в онлайн, качество вряд ли будет выше.

  • Пожалуйста, перестаньте рекомендовать Git Flow
    +3
    при закрытии обычного бранча он заливается только в девелоп, а хотфикс-бранчи льются одновременно и в девелоп, и в мастер

    Т.е. хотфиксы не тестируются, сразу в прод?
    Не задавались вопросом, откуда берется потребность в хотфиксах? Их же не должно быть в CD?
  • Пожалуйста, перестаньте рекомендовать Git Flow
    +1
    А это накладные расходы, т.к. CI фактически нет.
    И расписание мержей веток перед релизом, т.к. всем нужно успеть…
    Я не говорю, что это однозначно плохо — сам такую модель внедрял. Но поддерживать ее трудозатратно, т.е. теоретически есть резерв повышения эффективности. Но практического решения пока не нашел.
  • Пожалуйста, перестаньте рекомендовать Git Flow
    +3
    На это могу ответить цитатой из статьи/перевода
    Каждая модель ветвления подходит для соответствующих команд, культур и условий. Сторонникам CD подходит модель, максимально упрощающая процесс. Кто-то обожает разработку на основе trunk'ов (trunk-based development) и переключатели функциональности (feature flags).

    В CD патчи не нужны — там новые релизы.
    И в зрелой CD организации каждый коммит в транк обеспечивается ту же предсказуемость и стабильность, что мерж фиче-ветки в Вашем случае.
    В целом, у статьи только название провокационное, а так она вполне себе описывает зону применимости git flow:
    Если ваша компания придерживается месячного или квартального цикла выпуска ПО, а команда параллельно работает над несколькими релизами, то Git-flow может стать неплохим выбором.

    И заметим, никаких альтернатив в этом сценарии не предлагается.
    А было бы интересно…
  • Как я 12 лет создавал свой ЯП и компилятор к нему
    0
    Александр, не нужно писать новый язык, лучше найдите любую квалифицированную работу, изучайте то, что нужно рынку, и заочно получайте высшее образование.

    cine-lang.blogspot.com/2020/02/blog-post.html
    Подумав я понял, что бессмысленно продолжать это безумие. И решил писать новый язык с нуля.


    Здесь уже была ссылка на compiler.su
    Советую обратить внимание на страничку compiler.su/entuziasty-razrabotchiki-kompilyatorov-i-ikh-proekty.php
    Там очень часто встречается Статус: проект не развивается.
    А из успешных проектов могу назвать только Kotlin
  • Кто такой хороший QA?
    0
    Полностью согласен. Сборник бессмысленных анекдотов без всякой морали. Может забыли тэг «Юмор»?