Комментарии 144
Ну, справедливости ради - действительно стоит внести это в контракт.
Или сделать добровольным участие, но общественно порицать неучастие
Только в контракт, при чем об этом должно быть известно заранее при трудоустройстве. Программировать и разносить еду это несколько разные сферы деятельности, и человек должен знать что его ожидает.
Смотря кому.
DBA это не нужно, а вот PM, UX и frontend поможет погрузиться в реальное использование сервиса.
Понятное дело.
Но вообще если политика компании такая - может и всем.
Честно сказать, что основатель считает, что так - правильно.
Поэтому в контракте строчка "участвовать в контроле качества и тестировании продуктов кампании на всех этапах внедрения"
Ну да, если на сервере произошел дедлок в момент когда курьер доставил заказ, и ему не отметилась доставка вовремя, то это проблемы исключительно курьера. А не DBA.
Общественное порицание эквивалентно убийству - как это сочетается с добровольным не понимаю.
Да, это скользкий вопрос.
Я имел в виду, что для новых сотрудников - сделать в контракте пункт.
А со старыми нужно договариваться - либо менять контракт, либо сделать это общей практикой, основанной на договоренностях, но опциональной.
Со временем такой вопрос решится сам собой - либо сотрудники, которые не присоединяются к практике достаточно ценны, либо со временем уходят.
Вот имеено - это по больше части выдавливание неугодных сотрудников, которые видят в этой практике только блажь со стороны руководства. Конечно в идеале все должны быть коммуникабельны, инициативны... но не все человеки такие, есть те для которых общение напрямую с конечным клиентом, может быть очень сложно, в рамках той деятельности, что ему навязывают. Человек может быть нормальным программистом, но как курьер он может чувствовать себя не в своей тарелке. И получаем еще одно средство контроля - "какой ты программист, коли не справился даже с работой курьера". Плюс не все в команде должны точно знать нюансы работы курьера - потому что будут отбрасываться множество заведомо неприемлемых вариантов - все знают, что какие-то идеи нереальны, поэтому ее даже не будут обсуждать что может привести к стагнации.
И в данной инициативе, все видят только плюсы: тим билдинг, вникание в процессы..., но где минусы? Программисты становятся некой базой знаний для все остальных отделов - незаменимыми, т. к. к ним со своими проблемами идут все кому не лень, а когда такие люди уйдут из компании, то компания оказывается в ловушке.
Соглашусь с добровольным участием. Я всегда говорю - хорошо, что бы те, кто хочет, имели возможность делать, а те, кто не хочет, имели возможность не делать. Если человек очень болеет за проект - хорошо, пусть имеет возможность глубже его понять. Если не хочет - тоже хорошо, он на это не подписывался
Штука полезна, помогает понять бизнес, что ты имплементируешь. Что сильно увеличивает качество продукта зачастую и эффективность тоже.
Опыт есть, сам с подобным сталкивался, когда имплементировал продукты для местного рынка.
Но и также понимаю возмущающихся. Он код пришел писать, а не в бизнес процессы вникать.
Если считать программистов тупыми трансляторами ТЗ в код, то да. Но ведь обычно люди, пишущие программы - несколько лучшего о себе мнения.
Да и на работу выходят не только кодеры, но и люди, работающие над UI/UX, а им это очень полезно будет ;)
Так в том и фокус. Программисты то работают над задачами, а задачи ставят руководы - вот пусть они и разносят еду, вникают в нюансы.
Тогда это просто кодеры, а не разработчики.
А зачем им в это вникать, если от них зачастую ничего не зависит?
Всё зависит от тех, кто проявляет инициативу
Всё зависит от тех, у кого власть. Иногда её дают тем, кто проявляет инициативу. Но если перестараетесь с инициативой, вас уволят.
Как говорил мой бывший шеф: "власть не дают, ее берут"
Мой опыт показывает, что если просто много делать и ждать что тебе все предложат и все дадут, превращается в лошадь, которая работала больше всех, но председателем не стала
Помимо проявления инициативы ещё нужно настойчиво набирать на себя веса в принятии решений, вот тогда это уже работает
Вопрос не во вникании в бизнес-процессы, а в выполнении тяжёлого физического труда.
Сорванная спина, усугубляющееся плоскостопие, проблемы с венами на ногах - не самые приятные вещи, и офисный работник вполне справедливо рассчитывает не сталкиваться с такими проблемами.
Отправить поездить пару дней вместе с курьером, посмотреть изнутри бизнес-процесс - ок.
Отправить делать тяжёлую физическую работу человека, который не рассчитывал её делать(а может, и не способен) - так себе идея.
Ой-ой, спинку сорвал, раз в месяц подняв коробку пиццы, бедняжечка.
Бутыль воды в кулер поставить тоже специльного грузчика вызываете в офис?
Именно так. Сервисная служба занимается поддержанием жизни в офисе, кадровая - ведёт документооборот, IT - пишет новые сервисы и чинит старые. Это называется здоровое разделение труда и специализация
Сорванная спина, усугубляющееся плоскостопие, проблемы с венами на ногах - не самые приятные вещи
Согласен. Но только у разработчиков есть реальная возможность что то изменить в их работе. Может они смогут лучше прогнозировать спрос и разгружать доставку на нескольких человек, а не на одного (курьеры же тоже люди , и у них тоже спина болит). Или изобретут оптимальный вид транспорта, где все это влезает. А может это будет дроны, и память о грузе за спиной будет лучшим вдохновляющим фактором для создания идеального алгоритма! Столько умных людей просто кодят то, что им говорят, вместо того, чтобы реально решать проблемы!
Просто посмотрите наперед , в перспективу, на плюсы, а не на минусы.
Пусть так, но это должно быть по своей воле, без принуждения. Для кого-то работа - это в первую очередь работа за деньги, а не ради процветания человечества.
Во-первых, что-то изменить могут не разработчики, а бизнес. Пока выгоднее эксплуатировать курьеров в хвост и в гриву - будут это делать. Как только это станет невыгодно - гос. регулирование, большие выплаты по больничным за счёт предприятия, давление профсоюзов - тогда и будут оптимизировать.
Во-вторых, человек имеет право выбирать, на какие условия труда он согласен за свою зарплату. Разработчик выбрал сидячую работу в офисе(или дома на удалёнке), а тут приходит работодатель и заявляет: для лучшей мотивации в разработке вам необходима грыжа какого-нибудь позвонка, идите зарабатывайте.
И тут разработчик имеет полное право послать компанию по известному адресу.
Напоминает пресловутые "овощебазы" в СССР. Чтобы студенты и сотрудники НИИ не отрывались от народа. История ходит по кругу...
А почему у вас негативно окрашены те, кому практика физического неквалифицированного труда показалась несоответствующей их уровною знаний? Ведь так оно и есть.
Ну да, эффективные менеджеры возмущены, что программисты не желают брать на себя их работу забесплатно.
Ну так и металлург-технолог часто не умеет вырезать аппендикс тем скальпелем, который он спроектировал.
Но даже если скальпель не слишком хорош получился - скажем, длинноват, или насечки на рукоядке не хватает - то информация об этом должна прийти металлургу через производственную цепочку тестировщиков, аналитиков и постановщиков задач, а не через "Эй ты, иди сам попробуй отрезать ему эту хреновину - видишь как неудобно?"
Гемба как раз чаще и встречается в компаниях с большими иерархиями. Они ее и породили.
А подход "не хочешь - увольняйся" всегда идет в ущерб его практикователям, потому что между этими шагами может быть много промежуточных для урегулирования споров. Можно еще про очередь за забором при этом упомянуть. И остаться без сотрудников.
Во время работы в Сбере (когда уже Греф пришел) - регулярно руководство отправлялось в гэмба-походы, отработать (под руководством опытного спеца) день на рядовом рабочем месте. Насколько помню, эффект, особенно в начале, был отличный. Сам ездил в региональные отделения и работал на месте.
Поэтому "за", программистов надо периодически делать пользователями собственного софта - не тестерами, а именно конечными реальными пользователями.
Гемба, все-таки, не про программистов - а про руководство.
Отправить тимлида посидеть на первой линии - полезно. Отправить тимлида возить доставку - странно.
В чем разница?
Сходу миллион проблем, которые можно прочувствовать приходит в голову
Допустим, у нас команда, отвечающая за бизнес-аналитику. Их задача - по собранным данным подготовить datalake для запросов аналитиков. Вот они там развернули шард из кликхаусов, выгрузку логов из всех временных хранилищ, метрики из промов и т.д. И вот там есть программист, который пишет обвязку поверх клика.
И вот его отправили в отделение. Посмотрел он на этот ужас из оперденя, и решил, что надо срочно поправить...
что?
>что?
Резюме и статус "не в поиске работы"./s
Конечный потребитель вашего продукта - аналитики. Думаю, команда работает с ними и так довольно тесно, но да, можно сделать программиста аналитиком на недельку.
Ну зависит от того, в какие процессы погружен конкретный человек и какая у него зона ответственности. Если тимлид принимает решения в области UX, сценариев и других пользовательских областях (а такое часто бывает), а их основной продукт - доставка, то может и быть полезным.
Возможно это грубое решение, но учитывая, какие бывают проблемы с отрывом разработки от конечного потребителя, эффективное.
Практика выглядит полезной. Далеко не везде применимо, но глядя на многие мобильные приложения складывается впечатление, что сами разработчики им не пользовались и не собираются пользоваться по назначению.
Некий вид наказания и/или воспитания... Я бы понял, если бы за это было бы какое-то поощрение (например, определенную долю от компании (акции) и у тебя уже будет мотивация вникать во все бизнес-процессы...). Самое интересное, что у нас это практикуется намного чаще и считается нормой, наследие совка наверное, но в совке все было "общее"... Или хотя бы, если программисты работают курьерами, то на это время курьеры становаться программистами.
если бы за это было бы какое-то поощрение
Там очень часто выдают бонусы акциями. А если ты сам пользуешься своим продуктом, то и продукт получается гораздо качественней. А значит, у компании все будет в порядке с ростом. А значит, ты получишь кучу бонусов своими акциями. Профит!
Да бонусы это хорошо, но принесение в жертву мне не очень нравится. Т. е. получается обесценивание либо программистов, либо курьеров (офк все костыли, но пока компания же не может отказаться и от тех и от других) -> должна быть симметрия - программисты 1 день курьеры, значит курьеры в это же время занимают должность программистов. А на месте программистов, я бы всем отделом перешел работать в курьерскую службу...
Почему обесценивание? Представьте, что разработчика отправили на курсы по развитию скилла. Разве это значит, что он недостаточно компетнтен для выполнения текущей своей работы? Нет, это прокачка и вклад в сотрудника, чтобы он на проблему мог посмотреть со стороны своего пользователя.
Тоже так считаю - побыть денёк курьером за зарплату программиста можно трактовать как бонус ?
Доставка еды это оплачиваемый выходной и проходить спокойно на воздухе? Думаю курьеры с вами не согласятся :)
«Лучший отдых – смена деятельности» (с) Павлов, Сеченов, Ленин, Конфуций... ;)
PS: Поэтому с удовольствием езжу в командировки, пусть там условия и не такие комфортные, как в офисе, но зато глаза отдыхают и мозг переключается.
Думаю, что за зарплату программиста курьеры бы тоже с удовольствием занимались своей работой.
Сразу видно, что вы слабо себе представляете работу доставщика еды. Их почти не осталось пеших, потому что пешком сложно укладываться в срок доставки. Не уложился - штраф. Это не прогулки на свежем воздухе, это каторга, выжимающая здоровье за пару лет работы.
Думаю, штрафы профессиональных курьеров неприменимы к программистам, которые занимаются этим раз в месяц. Поэтому остаётся только свободная прогулка в удобном темпе. Но я могу ошибаться.
Тогда у программиста не будет складываться понимание того ада, который он создает для курьеров, и вся задумка оказывается бессмысленной.
Ад для курьеров проектируют владельцы продуктов, менеджеры, директора, бизнес вообщем. Программист только реализует его, не имея права голоса.
Каждый сам для себя решает, достойным ли он делом занимается, не кривит ли душой. За последний месяц мы узнали, например, что во ФСИН есть айтишники, занимающиеся организацием и хранением видеозаписей пыток и изнасилований заключенных. Не то что бы они сами пытают, нет, но они знают, в чем участвуют.
Многие из нас упустили момент, когда айти компании, делавшие полезные продукты вроде поиска в интернете или навигации по картам, вдруг стали ключевыми и жестокими эксплуататорами миллионов «лишних» людей.
Получается, что DoorDash сам роет себе яму, потому что программисты преисполнятся состраданием к курьерам и уйдут из компании?
Большинство этих программистов благодаря тому, что делают сейчас, в старости не смогут быть даже курьерами.
IT-компании сейчас эксплуатируют курьеров, таксистов и кладовщиков с помощью программистов, чтобы сделать полностью или почти полностью автоматические решения, требующие минимального участия человека. Нас в ближайшее время ждут роботизированные склады, товары с котрых будут грузить в автомобили с автопилотом, в которых будут перевозиться также маленькие роботы-доставщики, которые будут таскать грузы от этих автомобилей конечным потребителям. И когда это заработает, программист окажется таким же безработным, как и вчерашние курьеры с кладовщиками.
Да, работа курьером или таксистом - во многоим искусственная занятость, особого смысла в ней нет. Но никто не строит мир, в котором для всех людей будет что-то более осмысленное.
Вы занимались доставкой или таксовали через агрегатор в последние три года? Раньше и таксист, и курьер были вполне себе человеческими профессиями. Но благодаря агрегаторам всё радикально изменилось.
Курьеров навалом только потому, что для любого безработного это способ пойти и получать деньги сразу. Во врачи так так не получится.
Рисованные казалось бы большие зарплаты сбиваются до абсолютного минимума штрафами за каждый чих и клиенто-ориентированным подходом, когда в каждом чихе виноват курьер.
Таксисты не спешат поступать в мед, потому что бумажка в виде диплома российского вуза теперь мало что стоит и мало что дает по жизни. Это работало, пока был социальный лифт, условием продвижения по которому было высшее образование. Но у этого лифта тросс оборвался еще году в 2012.
Вот Вы сами и ответили, зачем нужно разработчикам пользоваться своим продуктом. В данном случае "сроки доставки" должны быть максимально реалистичны и тщательно просчитаны (и оценены риски). Т.о. те, кто придумывал и кто имплементировали алгоритмы расчёта сроков доставки смогут лучше оценить качество своей работы как программиста.
Сроки доставки определяет не программист, а менеджер. И его ничто не ограничивает.
Мне интересно, каким образом менеджер может определять сроки без помощи программных комплексов? Как он учитывает, что не всем нужно здесь и сейчас, некоторым нужно вовремя (которое они сами выбрали)? Задачу коммивояжёра решает и графы доставки строит?
Или как в древние времена, царь/князь приказал, Иван сделал?
У меня рядом с домом есть хозяйственный магазин, где продавщицы и директриса работают с советских времён, всё те же. Потому что это реальный коллектив и директриса создает для них хорошие условия, дорожит каждой. Короче, занимается на самом тем, чем должны бы заниматься многочисленные управленцы в крупных компаниях.
В аггрегаторах такси и доставки менеджер занят тем, что изучает данные и смотрит, как ещё эффективнее вычерпать ресурсы людей. Курьер ссыт в бутылку, чтобы не тратить время на туалет? Прекрасно, подскажем это всем курьерам через «неофициальный» чат и изменим нормативы так, чтобы на туалет времени не оставалось. Курьер лихачит на электросамокате без прав и шлема? Прекрасно, изменим нормативы так, чтобы всем нужен был электросамокат или хотя бы велосипед...
Идилия будет продолжаться до первого сильно недовольного клиента.
Ещё клиентами надо)
Ну и, конечно, это не должно становиться сюрпризом для разработчика. Надо сразу предупреждать при приёме на работу.
Интересный подход который должен принести пользу. Опыт внутри бизнеса с разных его сторон - очень полезная практика с точки зрения расширения кругозора и понимания как внутри все устроено. Возможно раз в месяц работать именно курьером - это много, но если каждый месяц эта должность будет меняться (1 раз курьер, второй - тех поддержка и т.д) - то звучит очень интересно. Главное что бы курьера без образования не посадили код писать хДД
А еще интересно, выступали только программисты или люди с других должностей тоже против? ПРосто выглядит это сейчас, что ТОП менеджемент работает курьерами а программеры (какая то их часть) - артачатся. Особенно расстраивает фраза "что они против таких занятий, так как их образование и технические знания освобождают от любого физического труда на работе" - выглядит как некое зазнайство.
P.S. Случаи, когда с текущей должности, отправляли на более низкую для ознакомления были и не раз. Некое время назад работал в фарм-дистрибьютере (топ 1 в России) аналитиком, в отделе складской логистики. Отправляли несколько раз на склад поработать обычным сборщиком заказов. Аналогичная ситуация была ранее, в другой компании, связаной с детской одеждой. Там успел побывать в шкуре оператора, курьера, складского рабочего (хотя подобный опыт был ранее, в период когда только только начинал работать). Я это к тому, что на своей шкуре пробывал подобную практику, и своя польза от этого была.
Считаю эту практику полезной - программист ведь не просто "пишет код". Я, когда работал в Яндекс.Метро, иногда занимался тем, что катался по этому самому метро, замеряя время и осматривая местность. Вообще, работа программиста не должна быть зациклена на "написании кода", нужно интересоваться той сферой, к которой этот код прикладывается (в моём случае - интерес к транспортному планированию вообще был и остаётся гораздо выше, чем к инструментам информатизации).
Да и вообще, 1 день в месяц заниматься непрофильным трудом (причём не "грязной работой", а вполне обычным), по трудозатратам сопаставимым с профильным - это банально интересное приключение, чтобы не заскучать на работе и продышаться.
Боюсь, сотрудники завода, как и программисты, не принимают решения, сколько башен делать у танков, а выполняют волю заказчика. Многобашенные танки - не ошибка заводчан, а инерция мышления военных заказчиков еще с Первой мировой - что в поле будет бесконечная череда траншей, перепутанных колючкой, и танк должен туда доползти вместе с атакующей пехотой (отсюда тихоходность - а зачем быстрее?), и там поливать пулеметами во все стороны сразу - отсюда могобашенность. Как говорится, старые генералы всегда готовятся к прошлой войне.
А когда оказалось, что в Финляндии вместо беззащитных окопов - бетонные доты, к которым требуется срочно подъехать под огнем поближе и уничтожить прямой наводкой, потому что иначе не достать - отсюда вышло требование одной башни с мощным орудием, и соответствено бронирование.
Да только глупо и дорого для военных получать такие знания на практике, ценой жизни лучших конструкторов-заводчан. Немцы почему-то отказались от многобашенных танков куда раньше, и без всякой Финляндии. Так и здесь, вместо того, чтобы отрывать дорогостоящих IT-специалистов от их прямых обязанностей - наняли бы пару толковых эргономистов-тестировщиков, и пусть катаются с курьерами, наблюдают, хронометрируют, а программистам выкатывают толковые ТЗ.
Я некоторое время подрабатывал в Skip The Dishes, это похожий сервис. У них в общем неплохое приложение, но некоторых элементарных фунций не хватает. Например, сумма заработанного за период - можно только вручную сложить отдельные доставки. И нельзя скопировать цифры, чтобы, например, отправить себе для отчета. Ну и много чего. Я даже через свои контакты Линкдин в Виннипеге вышел на разработчиков и написал им. Они прочитали сообщение и промолчали. Я хотел сторонний парсер для их сайта написать, но я с ними заключил контракт, а там были мутные пункты про то, что я не должен "портить" или "ломать" их софт, и я передумал.
Если бы их разрабы выходили в поле иногда, таких досадных недочетов бы не было.
Для того, чтобы фиксить такое, "в поле" должны выходить не разрабы, а дизайнеры и всякие там продакт-оунеры/продакт-лиды. И просто адекватно реагировать на фидбэк - если на него плюют внутри компании, то какая разница, потрогали вы сами приложение или нет.
Я думаю, вы правы. Может, тестеры должны выходить. Но выходить кто-то должен.
Я не настаиваю на том, чтобы синьор памидор лично бегал с сумкой ?
В рамках этой программы все сотрудники компании от программистов до топ-менеджеров должны раз в месяц выполнять работу курьера или других сотрудников, чтобы понимать в реальности, что они делают не так в своих командах, и как это сказывается на работе других и бизнеса компании в общем.
Ну так-то все и выходят, включая руководство. ;)
Спасибо, я умею читать. :)
Вот только я говорю ровно то, что всем выходить нет никакого смысла, кроме дешёвого пиара для компании. Не потому, что это ниже чьего-то там достоинства, а потому, что средний разработчик не получит от этого никакой пользы, а средний пользователь скорее всего получит плохой экспириенс, потому что люди часто медленные или неуклюжие.
У меня такое ощущение, что я или очень плохо изъясняюсь, или мои сообщения старательно не читают. Не знаю, что из этого правда.
Ещё раз: менеджменту так делать смысл есть, потому что они принимают решения по продукту и политике развития. Среднему бэкэнд-программисту/бухгалтеру/офис-менеджеру - нет, совсем нет.
Да нет ничего полезного для бизнеса и клиентов в том, что человек, работа которого - весь день подписывать документы/наливать кофе/перекладывать из базы в джейсоны/сводить дебет с кредитом, пойдёт сам заказы доставлять (или какой там ещё у компании бизнес). А в огромном количестве случаев ещё и совершенно нереализуемо.
Увольняться им надо
Когда я встречал подобную практику для разработчиков, она нередко конфликтовала с реальностью:
1) Проблемы иерархии. Разработчик чаще всего имеет над собой начальство (тимлид, продукт-менеджер, проджект-менеджер, продукт-овнер, техдир), и это начальство в большинстве случаев при выдвинутых предложениях от разработчика знает за него, как делать надо, а как нет. И 90% продуктовых идей от самих разработчиков не принимаются под давлением опыта руководства, или отодвигаются в неприоритетный бэклог.
2) Проблемы фидбека. Люди искренне делятся впечатлениями в первые разы этой гембы. Дальше, видя, что после их впечатлений ситуация практически не поменялась, гембить уже и не особо хочется. Работа над фидбеком практически не ведется, т.к. клиентский фидбек оказывается приоритетнее.
3) Проблемы однобокости. Почему-то когда говорят, что разработчик должен быть погружен в бизнес, умалчивают о том, что тогда и бизнес должен быть погружен в разработку. Он же тоже станет лучше понимать процессы разработки и сможет оставить кучу фидбека про нее. Но почему-то вот никто из предлагателей погружения разработчика в бизнес не хочет сам хотя бы денек-два позакрывать простенькие баги в коде, и ему это становится резко не нужным, т.к. сразу появляется море неотложенных дел, да и вообще он не этим в компании занимается. Плюс это работает только вниз по ирерархии (почему разработчику не предлагают попробовать позаниматься продакт-овнерством, например?).
Я считаю, что подобная практика как раз хороша для людей, которые принимают решения (читай, начальников любых уровней). Рядовой разработчик к таким людям не относится, и его порывы после гембы не дают должного эффекта от данных мероприятий. Лишь небольшое расширение кругозора. И код писать он качественнее от этого точно не будет.
с напряжением свыше 1000 Ватт
Такие высказывания непростительны даже гуманитариям. Вроде как единицу измерения напряжения еще в 7 классе школы проходят.
Читал на баше несколько лет назад историю, не нашел сходу оригинал, но смысл постараюсь передать:
В одной конторе был товарищ, писавший софт для какого-то промышленного прибора. Часто возникали ошибки, отправляли апдейты на места и почему-то пользователи реагировали на ошибки и необходимость перепрошивки приборов очень агрессивно.
В итоге после очередного исправления за товарищем приехали злые вахтовики, посадили в машину и повезли в зимнюю тундру, привезли к какому-то объекту и предложили перепрошить оборудование. На вопрос "а где оно", показали вниз, дескать - находится на 2 метра глубже вместе с контролируемым объектом, мол откапывай и перепрошивай...
Так что глубокое понимание бизнес-процесса зачастую полезно даже кодеру. :)
Идея правильная, реализация - на двойку.
Программисты при сборе данных должны не сами работать курьерами, а должны сопровождать курьеров в течение дня - выполнение работы самостоятельно часто даёт совершенно неправильный фидбэк, в то время как наблюдение за профессионалами позволяет обнаружить совершенно неожиданные для программистов вещи.
Если программист сам использует свою программу - даже когда выполняет работу курьера - то он всё равно использует свои привычки и знания, которых настоящие курьеры не имеют, соответственно то, что очевидно ему, совершенно неочевидно обычным курьерам.
И наблюдать за профи и самому работать и обучать пользователей собственным примером.
Я согласен с вами - это лучший вариант
Думаю подобная штука с доставкой еды полезна тем командам которые занимаются именно приложением для разносчиков, вряд ли их так уж много.
Писал велосипед из-за того, что начальству не хотелось внедрять нормальный продукт с бюджетом и подрядной организацией и вообще, потому что нужно показать, что мы тоже можем как головная организация (только без специалистов, денег и ТЗ). Я сам ходил на места и ругал пользователей за отсутствие умений, которые мне кажутся самим собой разумеющимися и которые подразумевал при разработке
После окончания основных работ уволился. Начальство считало, что я ушёл из-за того, что я был расстроен от общения с пользователями, а не потому что бардак.
Не хотел бы я писать софт для полёта на Марс и раз в месяц тестировать его вживую
Средний офисный сотрудник, как правило, имеет далеко не лучшую физическу форму и иммунитет. Поэтому он разумно будет сопротивляться выполнению физической работы, не имея должной подготовки. И будет прав.
А тех, кто считает нормой такой принудительный труд, надо самих отправить работать курьером в Delivery Club в -30 на велосипеде.
Вот потому и не имеет, что боится даже раз в месяц из офиса нос высунуть
И будет прав.
Так может ему как раз и стоит заняться физкультурой, чтобы поправить физическую форму и (возможно) иммунитет?
Про езду в -30 на велосипеде - ну да, полезно. Например, станет понятно какого размера должны быть элементы управления чтобы в них можно было попасть толстой зимней перчаткой.
Конечно стоит заняться физкультурой и закаливанием. Вот только самостоятельно, по своей воле и в подходящем ритме а не "вот тебе торба и велосипед и ехай".
>Например, станет понятно какого размера должны быть элементы управления чтобы в них можно было попасть толстой зимней перчаткой.
Чтобы не промахиваться по кнопкам в перчатках в -30, нужен уже планшет.
Так надо или он "будет прав"?) Не нравятся условия - не работай там, в чем проблема то.
Про планшет - а как его возить с собой на велике зимой? Вот чтобы таких предложений не возникало, как раз и стоит попробовать.
Заниматься спортом надо, но заставить человека это делать никто не имеет права.
В IT пока что проблем с поиском работы нет, так что да можно и уволиться из конторы, которая заставляет тебя в нарушении всех законов и договоров исполнять не относящиеся к должности обязанности. Но это уже личный выбор каждого.
>Про планшет - а как его возить с собой на велике зимой?
Работать велокурьером в -30 в принципе не сахар, и ни планшет ни улучшенная версия приложения ситуацию сильно не облегчит. Это скорее из разряда абсурдных предложений.
Если этого нет в договоре - да, плохо, должно быть. Тут в комментах уже много кто про это писал, спорить тут смысла нет.
Про -30 не я написал, но даже в -10 уже все несколько не так как летом и разработчику стоит это знать.
Ну у меня уже при любой температуре ниже нуля пальцы отваливаются, так что я в принципе не могу пользоваться телефоном на улице. А в перчатках - только на планшете можно попасть по кнопкам.
Тут скорее проблема в том, что человек в принципе не должен исполнять такую работу. Курьер в зимнее время должен либо ездить на машине, либо быть роботом, но это пока только мечты.
1) Я бэкэндер, проектирование интерфейсов мобильного приложения - которым по-хорошему должны заниматься вообще дизайнеры, фронтэндеры (в данном случае не веб-, а мобильные, вероятно) только уточнять и вносить минимальные корректировки - меня касается ровно никак, а базы данных и микросервисы работают одинаково в -30 и +30, пока это не температура в серверной. :)
2) Это всё прекрасно, но я, например, не умею кататься на велосипеде, и можно хоть пять штук их мне выдать - быстрее я от этого заказ не доставлю. И я гарантирую, что я не первый и не последний человек на планете, который не умеет ездить на велосипеде. Так что, клиенты подождут, пока я пешочком доползу туда-сюда? Меня эта инициатива смущает не с точки зрения "чего это разработчики трудом для челяди занимаются" - это и правда глупо, а с той точки зрения, что от этого в среднем будет страдать клиент, а разработчик выигрывать ровно ничего. :)
Бесполезная практика. Особенно если вызывает такое отторжение.
В Додо пица тоже пиццу, как расказывали, всем офисом жарят, но, по моему ни кто не жаловался.
Это вопрос именно про "дух и ценности". Начинать надо с них. А потом уже программист едет "в поле" на практику оценивать свой продукт. И желательно не рядовой, а "владелец продукта" в команде.
Подытог.
Выпускать "в поля" имеет смысл всех, но - например раз в год и выдав всё нужное - одежда, велик если надо итд. А так - пускать в "целевую аудиторию" отдела. Веб/мобилы - курьером и на 1 линию, в бэке - в отдел фронта, кто пилит внутренние вещи - туда где они применяются (кухня)... но гонять нужно менеджеров не меньше технарей, они ровно такие же участники процесса.
И очень важно, чтобы была по итогу адекватная обратная связь и комментарии шли в работу а не просто "нам важно ваше мнение".
А про "минус 40" - достаточно просто избегать практики на улице зимой. С другой стороны, это тоже опыт и хотя бы раз в жизни можно и побегать в минус 40.
И ещё момент. Если сразу это не было обозначено - можно делать добровольно, но за премии/акции/доп выходные. Ну и лояльность тут будет видна, если человек и как программист не очень, и в поля не хочет - это будет первый кандидат на сокращение при любых изменениях. Вариант - без таких подмен нельзя получить повышение в должности (не зп, которую нужно индексировать, а именно продвижение). Опять же, актуально прежде всего менеджерам, инженерам всего несколько шагов доступно - условно тимлид, техлид)
Много лет назад я работал в одном агенстве, которое занималось всякой рекламой и организацией offline мероприятий. Я там был единственным IT-ом, который закрывал вопрос наличия сайтов у этих мероприятий и организаций.
В какой-то момент начальству в голову пришла гениальная идея. Погнать всех на улицу раздавать рекламные листовки случайным прохожим. Каждому всучили под 500 флаеров и погнали. Мне, блин, тоже.
Тут стоит отметить, что я всегда был и есть против навязчивой рекламы. А более навязчивой рекламы чем промоутеры, которые пристают к тебе с вопросами, сложно ссыскать. Плюс то, что моя интровертная технарская душа была совсем не приспособлена к диалогам вроде "приходите в наше казино, у нас скидки бла-бла". В общем день не задался, я сгорал от стыда :-D
От последующих подобных акций мне удалось отвертеться. Правда с некоторыми потерями. Шеф при любом удобном случае не забывал подчеркнуть, что эти ваши IT-ки какие-то странные (а если более конкретно — "аутисты", но по-доброму, не со зла).
С тех пор всякие бредовые вылазки я воспринимаю скорее негативно. А если программист будет софт для шахты разрабатывать? Надо будет раз месяц работать шахтёром? Или может всё же лучше, вынести эти вопросы на уровень project management-а? Ну и организовать по уму? Например проводить опросы среди потребителей продукта. Ещё можно взять человека хорошо знающего продукт, и именно ему пройти весь путь использования продукта "под ручку" с реальным юзером этого продукта? Ну т.е. примерно то же самое, что в статье, но не "случайным образом", а прицельно: когда анализ проводит светлая голова, хорошо знающая продукт, а в поле рядом находится реальный пользователь (а не программист), который кнопки кликает так, как ему ведомо, а не как задумывал программист. Выхлопу будет куда больше.
Ну, а слесарями пойдете? Эксплуатацию жилых домов автоматизировать. А дворником? Допустим, надо рассчитать тариф. День работы (которую, скорее всего, придется переделывать), стресс на месяц: две недели отходить, две недели ждать нового эксперимента.
Или достаточно того, что я скажу или, там, покажу фото: здесь асфальт ровный как стеклышко, а здесь корни и колдоебны, и сто кв м в первом случае равно 20 кв м во втором. И принесу трубу: вот это из пятиэтажки, вся ржавая, "фонит", а эта пластиковая, по германской лицензии из монолита.
Можно жалобы жителей дать, они все в базе, в них все указано: и недогревы, шумы в лифте, и то, что лавочку сломали, а надо сделать, а теперь убрать лавочку, а то там сброд и наркоманы.
Мне вот этот пример очень понравился: @YMAпишет: "злые вахтовики, посадили в машину и повезли в зимнюю тундру, привезли к какому-то объекту и предложили перепрошить оборудование. На вопрос "а где оно", показали вниз, дескать - находится на 2 метра глубже вместе с контролируемым объектом, мол откапывай и перепрошивай...".
Хорошо, а по-другому нельзя было донести проблему? По телефону, например.
А что касается курьеров, то холтера купить одну на фирму и посмотреть, в каком вообще курьеры состоянии, пока ласты не склеил.
Мне видится, проблемы взаимодействия и бездумное копирование иностранного опыта, весьма ограиченного применения. Якокка да, каждую ездку ехал на новой машине, ему пригоняли любую машину, какая только есть на рынке, но он смотрел глазами потребителя, а за станок/конвейер чтобы вставал, такого не припомню в его книге.
Пианиста не учат в цеху музинструментов рояль, понимаете, выстругивать, полировать там. Пианист не для этого.
Хорошо, а по-другому нельзя было донести проблему? По телефону, например.
В идеальной организации, где-нибудь в Лотлориене - такой проблемы просто не возникает, всё продумывается заранее, проблемы решаются оперативно в соответствии с их критичностью и т.д.
А в реальности по телефону не достигается нужный уровень эмпатии. Придя с гембы, тот же программер скажет коллегам - "там реально б## пи#### на###", и вопросы начнут решаться несколько быстрее, чем через обращение в ТП и открытие тикетов.
Мы сейчас пытаемся доказать IT-шникам, что подвисание сервера Exchange на минуту при массовой рассылке легкого письма - это ненормально. Таких писем в день бывает по десятку и больше, при этом повисают и клиенты - а там задачи, календарь и т.д. По их мнению, всё в пределах допустимого. Думаем натравить бухгалтерию и юристов - для эскалирования эмоционального уровня проблемы. :)
в моем детстве это называлось "на картошку", похоже выросло поколение менагеров картошки незаставшее.
Программисты DoorDash жалуются, что их заставляют доставлять еду