Да, я читал и не нашел явного пункта, запрещающего блокировать телеметрию (это же в теории можно сделать вообще не трогая ОС, а на внешнем роутере, например). Поэтому и спросил, возможно, кто-то знает больше по этому вопросу.
> 4. Члены команды должны максимально плотно взаимодействовать друг с другом
На практике это тяжело сделать. Если команда маленькая и проектов больше чем людей, то каждому суждено вариться в своем хозяйстве и на вникание в чужое тупо не будет времени. Если команда побольше, то уже будет разделение по обязанностям и все равно проектировщик базы вряд ли будет вникать в нюансы фронтэнда. Не было опыта работы в совсем больших коллективах, наверное, там это применимо.
От себя добавлю любимый принцип «Сокращать асапы». Всякий раз когда мы на практике пытаемся применить методологии разработки вместо банального выделения приоритетных задач в трекере, обязательно возникают задачи плана «баг в проекте нужно закрыть не позднее вечера» или «клиент заплатил нам за эту функциональность, запуск уже завтра» и вся методология ломается. Асапы — это, конечно, неизбежное зло, но с точки зрения менеджера/аналитика нужно понимать последствия (говнокод, в продакшн без тестирования — как в Марсианине ракету запускали, куча нервов) и выставлять задачу как критическую только в критическом случае.
А использование подобных штук нарушает лицензионное соглашение? Оно ведь не модифицирует dll, просто перекрывает хосты, на которые уходит телеметрия, верно?
> Государственная или полугосударственная фирма либо фирма, у которой основная деятельность никак не связана с ИТ
Я описал позитивные стороны того, что стоит в этом предложении после «либо». Опыта работы в государственных организациях у меня нет :)
Эээ, совсем мимо комментарий. Я писал о работе в компании, в которой разработка софта — побочная задача («не айтишная»). Про «гос. организации» вообще ни слова.
> Чем выше требования к ПО и чем выше квалификация девелоперов, тем чаще пишутся свои библиотеки.
Видел команду, написавшую свой минималистичный движок базы данных для их продукта. Долго шутил про «велосипеды», пока не увидел результаты сравнения тестов их узкоспециализированной бд со стандартными SQL и NoSQL решениями. Разница на пару порядков не в пользу универсальных баз. С тех пор шучу осторожнее. :)
> Ну а вообще не очень уверен, что на учебных сайтах можно реально чему-то научиться
Вот тут не соглашусь. Подписка на www.pluralsight.com окупает себя многократно (либо из торрентов при желании). Требуется лишь знание английского на уровне понимать техническую речь на слух (а часто еще и субтитры есть). И на телефон можно скачать.
> Не все занимаются фуллстеком, слишком много нужно знать
Классно же уметь все, начиная от покупки сервера, заканчивая микрооптимизациями в коде запросов, разве нет? Ну серьезно, если человек N лет занимается исключительно бэкендом, неужели не возникает интереса к остальным частям системы, хотя бы просто по фану. Или желания самому с нуля создать законечнный продукт, хоть и маленький, хоть и не везде идеальный, но от А до Я свой (сразу оговорюсь, здесь не идет речь про «не использовать фреймворки», как раз наоборот — без фреймворков с таким подходом свой продукт можно годами делать).
Вообще, все что описано в вашем и моем комментариях — это конфликт концепции микросервисов vs концепции архитектуры со слоями. Аналогично и с распределением задач. Можно взять десять человек, где один хорошо знает БД, другой фронтэнд, третий data science и тд или взять десять «оркестров», которые будут работать в пределах небольших проектов (связанных с другими понятными и документированными интерфейсами), но внутри своего проекта делать все-все-все. Мне оказался ближе второй подход.
Некоторые соображения по поводу п.4, из личного опыта (делаю ЭТО уже семь лет подряд в НЕ айтишной компании и счастлив). Из плюсов:
— У многих (в том числе и у меня) есть комплекс «работы на дядю». Когда у тебя есть возможность выбора всего, начиная от платформы разработки, заканчивая временем прихода-ухода с работы, комплексы удается успешно подавить. Многие мои одногруппники работают в разработке в больших конторах типа мейла или майкрософта, но лично по мне гораздо приятнее в маленьком и уютном местечке, где есть возможность повлиять на все происходящие процессы.
— Учиться вообще не сложно, если есть личная мотивация. Плюралсайт, линда, codeacademy и так далее. В большинстве тру айти-компаний не будет возможности поиграться в новые технологии, так как — корпоративный стандарт — писать все на (условно) Java. Был опыт работы в месте, где ВСЕ писалось на макросах экселя и гнусном VBA, только потому что однажды большой team lead решил, что «скакать по технологиям нельзя».
— Возможность вникать в не-технические сферы. В общем случае, изучить новый js-фреймворк — это фиговое развитие, а вот занимаясь автоматизацией бухгалтерии (из примера в статье) можно узнать много интересного о функционировании этой самой бухгалтерии. Мир многогранен и не заканчивается на айти-сфере. Почему бы не изучать его, особенно, если за это еще и платят.
— Понимание, что программирование — это инструмент достижения цели, а не цель. Кодить — классно, но главное тут все же — бабло :) Сделать костыльно и дешево лучше, чем идеально и дорого (заложившись, естественно, что будут затраты в дальнейшем на поддержку костылей). Постоянно сталкиваюсь с энтузиастами, которые готовы просидеть неделю в оптимизациях производительности или «переписать все под линукс», но при этом не оценивают, например, затраты на собственную з/п против профита от этой оптимизации.
— На собеседованиях регулярно вижу людей, которые пять лет программируют, понимают внутренности MSIL, но при этом не знают, зачем в БД нужны индексы. Нафига? Они же в «большой компании» программисты, а базами занимаются другие люди. Как, у вас программисты еще и должны на вебсервере IIS уметь сконфигурировать? Этим же админы занимаются. Angular? Нет, фронтендом занимался отдельный человек. Вежливо говоришь, что вот ваше приложение собрало гигабайты данных и неплохо было бы уметь это все пайтоном обработать и посмотреть корреляцию… — на этом собеседник вежливо откланивается.
Минусы понятны. Не стать начальником отдела из двадцати кодеров, потому что здесь никогда не будет двадцати кодеров. Застрять в болоте и вечно программировать на «языках с перфокартами», если самому не вытаскивать себя из зоны комфорта. Все в собственных руках, в итоге.
Да не, все ок. Данные же еще надо собрать. Конкретно в описываемом случае нужно было как-то упростить процедуру ежедневного похода с флешкой по 50 компьютерам, запуска экспорта в файл из досовского софта, ручного копирования файлов на флешку, а затем сливания всего на сервер обработки данных + собирать статистику типа скорости нажатия клавиш «бабушками», периоды отдыха и т.п.
Ладно, есть ощущение, что мы добрались до финала. Пообщались классно, всем спасибо, особенно автору статьи, благодаря которому мы все тут сегодня собрались :) Пользу я из этих диалогов извлек, надеюсь, мои посты тоже кого-то образумили.
То, что вы описываете — это точно полная жесть. К счастью, последние годы я работаю совсем в другой атмосфере и уже успел забыть о подобных проблемах. За советы спасибо, в мемориз.
p.s. Кстати, прочитав ваш комментарий, я задумался, что слово «офис» все по разному понимают. У меня это уютная комната с полкой моих книг, приглушенным освещением, музыкой, отличными коллегами и плакатом Леди Гаги на двери. А у кого-то — это душный шумный опенспейс на сотни человек. Многие негативные стороны мне банально не видны. Во многом лично мне нравится офисная работа, так как там я смог организовать себе продуктивное рабочее место, а дома — нет (когда у меня будет квартира с тремя комнатами в Мск, одну из которых я смогу оборудовать исключительно под работу — тогда вопрос легко решится не в пользу офиса :) ).
> Потому что спец по нейросетям, который ставил задачи
Тут ключевое слово «спец по нейросетям». Это техническая профессия, причем явно не низшего уровня. Мы говорим про не-технические профессии. Если вы любите абстракции — пожалуйста. Система учета потребления лекарств в ветеринарной клинике. Чувствуете разницу между этим и вашим примером?
> Может приведете пример такой сверхсложной, не формализуемой задачи?
Оке, вы меня есть раззадорить. Реальный экстремальный пример из двухлетней давности. Есть софт, написанный в 1994 году, с которым уже много лет работает команда брутальных бабушек-юзеров. Они работают с этим уже двадцать лет и выучили все комбинации клавиш не хуже игроков в мортал комбат, так что менять хоть чего-то тяжело. Софт работает на современных машинах в (!) досбоксе, взаимодействие через подпихивание файликов странного формата и перезагрузку досбокса (второй раз в эмуляторе при запуске все виснет). Для полного фана — документация отсутствует исходники какой-то (!) версии не собираются под более-менее современным компилятором. Вам нужно написать веб-апи с рест и джончиками для удаленного пропихивания из другой программы в эту определенных данных и получения обратно некоторого набора событий. Что делать. Собираем по крупицам информацию от всех возможных юзеров. Кто-то поделится файликами, которые они туда загружают (мы их потом проанализируем, зареверсим и зайдем еще раз для уточнения у пользователей, правильно ли мы интерпреируем результаты подпихивания нашему софту сгенеренного файлика). Выполнял не я, но представить решение этой задачи без регулярного хождения в отдел «бабушек» и уточнения слабо представляю.
Я вас уверяю, что существует огромное количество пользователей, работающих с компьютером на уровне «щелкнуть на ярлык на рабочем столе, а если ярлык пропал — поднимать панику». Но эти пользователи зачастую обладают знаниями о предметной области, которую вам поставили в задачу автоматизировать. Уже третий день вам объясняю, что это так, а вы мне не верите :)
Со всем вышесказанным согласен. Только это не отменяет опыта о снижении эффективности удаленщиков. Например, на прошлом рабочем месте (в той же области) пару лет назад отдельные аналитические задачи отдавали на аутсорс в восточную европу. Сдвиг времени, языковые барьеры (если бы все, кто знает что такое нормальное распределение, знал бы еще и в совершенстве английский — жизнь бы наладилась, точно), у них на весь офис 10 мегабит канал (привет, видео по скайпу), вместо общения напрямую с исполнителем — писать письмо менеджеру (испорченый телефон). Собственный отдел обработки данных в офисе работал в разы эффективнее. Причины отдачи на аутсорс были явно «политическими», либо, подозреваю, было дешевле (по сравнению с типовой оплатой в Мск).
Я не спорю, что все это можно наладить. Вкладывая тучу усилий. Просто работа локлаьно в офисе налаживается в разы проще.
> Колонку номер 1 умножаем на колнку номер 2 и делим еще на что-то
Это пример на уровне детского сада. Перемножить колонки может кто-угодно в экселе, тут мозгов и обращения к разработчику не нужно. Если у вас представление о data science, как о перемножении колонок, то о чем тут дальше говорить, извините за резкость.
> Не видел ни одного вменяемого специалиста который не может описать задачу в виде простых действий
А я вам в другой части этого треда уже говорил, что это характеризует исключительно ваш опыт работы с не-техническими областями. Если бы все вокруг могли переводить задачи своей предметной области в четкий структурный алгоритм, то не было бы профессии аналитика. Я много лет с этим сталкиваюсь каждый день, а вы говорите мне, что этого нет. Это есть. Вы — фрилансер и можете выбирать себе клиентов, чтобы они подходили под сказанное вами условие. Я в моей текущей работе — нет. Я вижу этих вменяемых специалистов, которые не могут описать задачу в виде простых действий, так как они составляют большинство представителей гуманитарных профессий. Не в обиду им (на мой взгляд, знание скажем четырех языков или закоулков законодательства РФ отлично компенсирует умение алгоритмически мыслить). Все должно быть разделено («кесарю — кесарево»). Я, например, ничего не понимаю в бухгалтерии, и, ответно считаю некорректным требовать от бухгалтера исключительно технической функции — описывать процесс в виде блок-схемы, а не, скажем, устно с моим конспектированием, а, затем, проверкой, верно ли я понял. Я не считаю, что выполнение прямых задач разработчика — это «вы привыкли когда на вас ездят».
> фреймворки
Scrum: Framework, not methodology
> TDD
Тут долго описывать. Общая идея, что при отсутствии понимания конечной цели (а она будет понятна только после сбора полной базы результатов по проекту) писать тест бессмысленно. Поэтому ТДД не подходит. Тестируется не ДО написания кода алгоритма, а только в самом финале (интеграционно). Но в большинстве случаев, вместо алгоритмического теста конечных результатов наметанный глаз социолога гораздо быстрее определит косяк или подозрение в неверности. Опять, яркий пример отличия от дефолтного бизнес-процесса разработки софта на заказ (ненажимающуюся кнопку в уи не протестируешь глазом в отличие от необычного для данной ситуации графика распределения).
> Возможность полноценной работы удаленно, очень многое говорит о конторе.
Она говорит о том, что технологический процесс ее работы позволяет каким-то его звеньям находиться удаленно. Цитируя вас же выше «Так что никакой америки вы не открыли. Не все занятия можно перенести на удаленку.». Я убеждаю вас в правоте ваших же слов. Невероятно :)
Вот это хардкор. :) И нормально хватает скорости местного вайфая? Люблю, если есть возможность, поработать из экзотических мест, но про метро как-то не задумывался.
Да, смущает. Оно имеет резко негативный смысл и в приличном обществе не употребляется в отношении людей. По крайней мере тех, с которыми вы желаете продолжить общаться.
Все же отвечу.
Удаленщики не плохие. Выше уже высказана не один раз и не только мной, кстати, мысль, что не любая работа подходит для фриланса или удаленки. Конкретно наша — плохо укладывается, в отличие от большого числа других, поэтому оправдано умеренное снижение оплаты (именно этот факт меня попросили объяснить в начале треда) за умеренное снижение эффективности работы относительно нахождения всех звеньев цепочки получения конечного продукта в едином офисе. Возможно, я некорректно выразился и мой пост восприняли как обобщение для всех возможных «работ», которые выполняют фрилансеры/удаленщики — тогда пардон.
> Все задачи должны обсуждаться в тикетах
Опять же, не один раз уже тут описал, что это не подходит для случаев получения задач от не-технических источников. Если выделена роль проджект-менеджера, который трансформирует поток нечетких мыслей заказчика в ТЗ, разбитое на ищьюсы в трекере — класс. У нас эта роль закреплена за разработчиками, так как «заказчик» сидит в соседней комнате и может напрямую расказать, какой, например, алгоритм обработки данных он хочет для этого проекта и какую систему их визуализации — тикеты тут бесполезная трата времени (если только закрытыми тикетами не считать продуктивность — вот это точно тех самых считать «по головам»), особенно, если этот алгоритм допиливается по ходу проекта, когда собирается база результатов исследования. Технарю понятно, что 100 тысяч и 100 млн записей базу можно и нужно разными средствами анализировать (100 тысяч я сделаю аналитику на обычном csv файле и тормозном LINQ, а 100 млн — уже нужно чего-то хитрее), а социологу понятно, что разные алгоритмы если вместо 50% питер и 50% москва собрали 70% питер и 30% москва (условно. в реальной жизни за такой сбор данных можно огрести и не дойти до этапа анализа :) ). Живой контакт, вербальное общение. Все это не заменяется скайпом (опять же, в конкретном описываемом мной случае нашей конторы, а не в общем).
> И на день вперед, и на неделю вперед, и даже на месяц вперед.
Есть плановая работа по софту, есть асап под конкретный проект (их запускается около 30-40 в день, для понимания). Допустим, клиенту помимо собранной базы ответов в экселе продали еще и визуализацию в вебе. Срок — до завтра. Нужно преобразовать массив данных в нужный вид, чтобы схавала система визуализации (данные в каждом проекте уникальные, а система, понятное дело, жрет стандартную структуру), да так, чтобы еще не тормозило на выходе (обычно — это кластеризовать близкие данные, но чтобы не получить косяков с точки зрения социологии) — все это требует взаимодействия с менеджером и постоянного уточнения задачи в процессе выполнения. Лучше живого общения тут ничего нет. Планировать появления таких асапов нельзя, как я уже говорил, даже с утра на вечер. Я рад, что многие могут планировать скрам на две недели вперед, и далее работать строго в рамках задач и мерить поинтами прогресс, но круг таких задач сильно ограничен — и дело не в косяке техпроцесса (он отлажен годами, в том числе и у более крупных конкурентов), а в разнообразии этих самых техпроцессов. Классическая разработческая компания, делающая софт по заказу — да (водопад, аджайл — все это описано в десятках книг). Все, что мимо этого — скорее всего требует пересмотра общепринятых концепций (в том числе и к удаленщикам).
Так. Либо у вас полностью отсутствует опыт автоматизации НЕ-шаблонных процессов в НЕ-технических областях, либо ваши последние N постов — чистый троллинг. В любом случае, продолжать дискуссию бесполезно.
На практике это тяжело сделать. Если команда маленькая и проектов больше чем людей, то каждому суждено вариться в своем хозяйстве и на вникание в чужое тупо не будет времени. Если команда побольше, то уже будет разделение по обязанностям и все равно проектировщик базы вряд ли будет вникать в нюансы фронтэнда. Не было опыта работы в совсем больших коллективах, наверное, там это применимо.
От себя добавлю любимый принцип «Сокращать асапы». Всякий раз когда мы на практике пытаемся применить методологии разработки вместо банального выделения приоритетных задач в трекере, обязательно возникают задачи плана «баг в проекте нужно закрыть не позднее вечера» или «клиент заплатил нам за эту функциональность, запуск уже завтра» и вся методология ломается. Асапы — это, конечно, неизбежное зло, но с точки зрения менеджера/аналитика нужно понимать последствия (говнокод, в продакшн без тестирования — как в Марсианине ракету запускали, куча нервов) и выставлять задачу как критическую только в критическом случае.
Я описал позитивные стороны того, что стоит в этом предложении после «либо». Опыта работы в государственных организациях у меня нет :)
Видел команду, написавшую свой минималистичный движок базы данных для их продукта. Долго шутил про «велосипеды», пока не увидел результаты сравнения тестов их узкоспециализированной бд со стандартными SQL и NoSQL решениями. Разница на пару порядков не в пользу универсальных баз. С тех пор шучу осторожнее. :)
Вот тут не соглашусь. Подписка на www.pluralsight.com окупает себя многократно (либо из торрентов при желании). Требуется лишь знание английского на уровне понимать техническую речь на слух (а часто еще и субтитры есть). И на телефон можно скачать.
> Не все занимаются фуллстеком, слишком много нужно знать
Классно же уметь все, начиная от покупки сервера, заканчивая микрооптимизациями в коде запросов, разве нет? Ну серьезно, если человек N лет занимается исключительно бэкендом, неужели не возникает интереса к остальным частям системы, хотя бы просто по фану. Или желания самому с нуля создать законечнный продукт, хоть и маленький, хоть и не везде идеальный, но от А до Я свой (сразу оговорюсь, здесь не идет речь про «не использовать фреймворки», как раз наоборот — без фреймворков с таким подходом свой продукт можно годами делать).
Вообще, все что описано в вашем и моем комментариях — это конфликт концепции микросервисов vs концепции архитектуры со слоями. Аналогично и с распределением задач. Можно взять десять человек, где один хорошо знает БД, другой фронтэнд, третий data science и тд или взять десять «оркестров», которые будут работать в пределах небольших проектов (связанных с другими понятными и документированными интерфейсами), но внутри своего проекта делать все-все-все. Мне оказался ближе второй подход.
— У многих (в том числе и у меня) есть комплекс «работы на дядю». Когда у тебя есть возможность выбора всего, начиная от платформы разработки, заканчивая временем прихода-ухода с работы, комплексы удается успешно подавить. Многие мои одногруппники работают в разработке в больших конторах типа мейла или майкрософта, но лично по мне гораздо приятнее в маленьком и уютном местечке, где есть возможность повлиять на все происходящие процессы.
— Учиться вообще не сложно, если есть личная мотивация. Плюралсайт, линда, codeacademy и так далее. В большинстве тру айти-компаний не будет возможности поиграться в новые технологии, так как — корпоративный стандарт — писать все на (условно) Java. Был опыт работы в месте, где ВСЕ писалось на макросах экселя и гнусном VBA, только потому что однажды большой team lead решил, что «скакать по технологиям нельзя».
— Возможность вникать в не-технические сферы. В общем случае, изучить новый js-фреймворк — это фиговое развитие, а вот занимаясь автоматизацией бухгалтерии (из примера в статье) можно узнать много интересного о функционировании этой самой бухгалтерии. Мир многогранен и не заканчивается на айти-сфере. Почему бы не изучать его, особенно, если за это еще и платят.
— Понимание, что программирование — это инструмент достижения цели, а не цель. Кодить — классно, но главное тут все же — бабло :) Сделать костыльно и дешево лучше, чем идеально и дорого (заложившись, естественно, что будут затраты в дальнейшем на поддержку костылей). Постоянно сталкиваюсь с энтузиастами, которые готовы просидеть неделю в оптимизациях производительности или «переписать все под линукс», но при этом не оценивают, например, затраты на собственную з/п против профита от этой оптимизации.
— На собеседованиях регулярно вижу людей, которые пять лет программируют, понимают внутренности MSIL, но при этом не знают, зачем в БД нужны индексы. Нафига? Они же в «большой компании» программисты, а базами занимаются другие люди. Как, у вас программисты еще и должны на вебсервере IIS уметь сконфигурировать? Этим же админы занимаются. Angular? Нет, фронтендом занимался отдельный человек. Вежливо говоришь, что вот ваше приложение собрало гигабайты данных и неплохо было бы уметь это все пайтоном обработать и посмотреть корреляцию… — на этом собеседник вежливо откланивается.
Минусы понятны. Не стать начальником отдела из двадцати кодеров, потому что здесь никогда не будет двадцати кодеров. Застрять в болоте и вечно программировать на «языках с перфокартами», если самому не вытаскивать себя из зоны комфорта. Все в собственных руках, в итоге.
Ладно, есть ощущение, что мы добрались до финала. Пообщались классно, всем спасибо, особенно автору статьи, благодаря которому мы все тут сегодня собрались :) Пользу я из этих диалогов извлек, надеюсь, мои посты тоже кого-то образумили.
Удачи и хорошей пятницы!
Текучка минимальная. Значит — кому-то интересно.
То, что вы описываете — это точно полная жесть. К счастью, последние годы я работаю совсем в другой атмосфере и уже успел забыть о подобных проблемах. За советы спасибо, в мемориз.
p.s. Кстати, прочитав ваш комментарий, я задумался, что слово «офис» все по разному понимают. У меня это уютная комната с полкой моих книг, приглушенным освещением, музыкой, отличными коллегами и плакатом Леди Гаги на двери. А у кого-то — это душный шумный опенспейс на сотни человек. Многие негативные стороны мне банально не видны. Во многом лично мне нравится офисная работа, так как там я смог организовать себе продуктивное рабочее место, а дома — нет (когда у меня будет квартира с тремя комнатами в Мск, одну из которых я смогу оборудовать исключительно под работу — тогда вопрос легко решится не в пользу офиса :) ).
Тут ключевое слово «спец по нейросетям». Это техническая профессия, причем явно не низшего уровня. Мы говорим про не-технические профессии. Если вы любите абстракции — пожалуйста. Система учета потребления лекарств в ветеринарной клинике. Чувствуете разницу между этим и вашим примером?
> Может приведете пример такой сверхсложной, не формализуемой задачи?
Оке, вы меня есть раззадорить. Реальный экстремальный пример из двухлетней давности. Есть софт, написанный в 1994 году, с которым уже много лет работает команда брутальных бабушек-юзеров. Они работают с этим уже двадцать лет и выучили все комбинации клавиш не хуже игроков в мортал комбат, так что менять хоть чего-то тяжело. Софт работает на современных машинах в (!) досбоксе, взаимодействие через подпихивание файликов странного формата и перезагрузку досбокса (второй раз в эмуляторе при запуске все виснет). Для полного фана — документация отсутствует исходники какой-то (!) версии не собираются под более-менее современным компилятором. Вам нужно написать веб-апи с рест и джончиками для удаленного пропихивания из другой программы в эту определенных данных и получения обратно некоторого набора событий. Что делать. Собираем по крупицам информацию от всех возможных юзеров. Кто-то поделится файликами, которые они туда загружают (мы их потом проанализируем, зареверсим и зайдем еще раз для уточнения у пользователей, правильно ли мы интерпреируем результаты подпихивания нашему софту сгенеренного файлика). Выполнял не я, но представить решение этой задачи без регулярного хождения в отдел «бабушек» и уточнения слабо представляю.
Я вас уверяю, что существует огромное количество пользователей, работающих с компьютером на уровне «щелкнуть на ярлык на рабочем столе, а если ярлык пропал — поднимать панику». Но эти пользователи зачастую обладают знаниями о предметной области, которую вам поставили в задачу автоматизировать. Уже третий день вам объясняю, что это так, а вы мне не верите :)
Я не спорю, что все это можно наладить. Вкладывая тучу усилий. Просто работа локлаьно в офисе налаживается в разы проще.
Это пример на уровне детского сада. Перемножить колонки может кто-угодно в экселе, тут мозгов и обращения к разработчику не нужно. Если у вас представление о data science, как о перемножении колонок, то о чем тут дальше говорить, извините за резкость.
> Не видел ни одного вменяемого специалиста который не может описать задачу в виде простых действий
А я вам в другой части этого треда уже говорил, что это характеризует исключительно ваш опыт работы с не-техническими областями. Если бы все вокруг могли переводить задачи своей предметной области в четкий структурный алгоритм, то не было бы профессии аналитика. Я много лет с этим сталкиваюсь каждый день, а вы говорите мне, что этого нет. Это есть. Вы — фрилансер и можете выбирать себе клиентов, чтобы они подходили под сказанное вами условие. Я в моей текущей работе — нет. Я вижу этих вменяемых специалистов, которые не могут описать задачу в виде простых действий, так как они составляют большинство представителей гуманитарных профессий. Не в обиду им (на мой взгляд, знание скажем четырех языков или закоулков законодательства РФ отлично компенсирует умение алгоритмически мыслить). Все должно быть разделено («кесарю — кесарево»). Я, например, ничего не понимаю в бухгалтерии, и, ответно считаю некорректным требовать от бухгалтера исключительно технической функции — описывать процесс в виде блок-схемы, а не, скажем, устно с моим конспектированием, а, затем, проверкой, верно ли я понял. Я не считаю, что выполнение прямых задач разработчика — это «вы привыкли когда на вас ездят».
> фреймворки
Scrum: Framework, not methodology
> TDD
Тут долго описывать. Общая идея, что при отсутствии понимания конечной цели (а она будет понятна только после сбора полной базы результатов по проекту) писать тест бессмысленно. Поэтому ТДД не подходит. Тестируется не ДО написания кода алгоритма, а только в самом финале (интеграционно). Но в большинстве случаев, вместо алгоритмического теста конечных результатов наметанный глаз социолога гораздо быстрее определит косяк или подозрение в неверности. Опять, яркий пример отличия от дефолтного бизнес-процесса разработки софта на заказ (ненажимающуюся кнопку в уи не протестируешь глазом в отличие от необычного для данной ситуации графика распределения).
> Возможность полноценной работы удаленно, очень многое говорит о конторе.
Она говорит о том, что технологический процесс ее работы позволяет каким-то его звеньям находиться удаленно. Цитируя вас же выше «Так что никакой америки вы не открыли. Не все занятия можно перенести на удаленку.». Я убеждаю вас в правоте ваших же слов. Невероятно :)
Вот это хардкор. :) И нормально хватает скорости местного вайфая? Люблю, если есть возможность, поработать из экзотических мест, но про метро как-то не задумывался.
Все же отвечу.
Удаленщики не плохие. Выше уже высказана не один раз и не только мной, кстати, мысль, что не любая работа подходит для фриланса или удаленки. Конкретно наша — плохо укладывается, в отличие от большого числа других, поэтому оправдано умеренное снижение оплаты (именно этот факт меня попросили объяснить в начале треда) за умеренное снижение эффективности работы относительно нахождения всех звеньев цепочки получения конечного продукта в едином офисе. Возможно, я некорректно выразился и мой пост восприняли как обобщение для всех возможных «работ», которые выполняют фрилансеры/удаленщики — тогда пардон.
> Все задачи должны обсуждаться в тикетах
Опять же, не один раз уже тут описал, что это не подходит для случаев получения задач от не-технических источников. Если выделена роль проджект-менеджера, который трансформирует поток нечетких мыслей заказчика в ТЗ, разбитое на ищьюсы в трекере — класс. У нас эта роль закреплена за разработчиками, так как «заказчик» сидит в соседней комнате и может напрямую расказать, какой, например, алгоритм обработки данных он хочет для этого проекта и какую систему их визуализации — тикеты тут бесполезная трата времени (если только закрытыми тикетами не считать продуктивность — вот это точно тех самых считать «по головам»), особенно, если этот алгоритм допиливается по ходу проекта, когда собирается база результатов исследования. Технарю понятно, что 100 тысяч и 100 млн записей базу можно и нужно разными средствами анализировать (100 тысяч я сделаю аналитику на обычном csv файле и тормозном LINQ, а 100 млн — уже нужно чего-то хитрее), а социологу понятно, что разные алгоритмы если вместо 50% питер и 50% москва собрали 70% питер и 30% москва (условно. в реальной жизни за такой сбор данных можно огрести и не дойти до этапа анализа :) ). Живой контакт, вербальное общение. Все это не заменяется скайпом (опять же, в конкретном описываемом мной случае нашей конторы, а не в общем).
> И на день вперед, и на неделю вперед, и даже на месяц вперед.
Есть плановая работа по софту, есть асап под конкретный проект (их запускается около 30-40 в день, для понимания). Допустим, клиенту помимо собранной базы ответов в экселе продали еще и визуализацию в вебе. Срок — до завтра. Нужно преобразовать массив данных в нужный вид, чтобы схавала система визуализации (данные в каждом проекте уникальные, а система, понятное дело, жрет стандартную структуру), да так, чтобы еще не тормозило на выходе (обычно — это кластеризовать близкие данные, но чтобы не получить косяков с точки зрения социологии) — все это требует взаимодействия с менеджером и постоянного уточнения задачи в процессе выполнения. Лучше живого общения тут ничего нет. Планировать появления таких асапов нельзя, как я уже говорил, даже с утра на вечер. Я рад, что многие могут планировать скрам на две недели вперед, и далее работать строго в рамках задач и мерить поинтами прогресс, но круг таких задач сильно ограничен — и дело не в косяке техпроцесса (он отлажен годами, в том числе и у более крупных конкурентов), а в разнообразии этих самых техпроцессов. Классическая разработческая компания, делающая софт по заказу — да (водопад, аджайл — все это описано в десятках книг). Все, что мимо этого — скорее всего требует пересмотра общепринятых концепций (в том числе и к удаленщикам).
Да, в большинстве комментариев меня убивает, что раз что-то (процесс программирования) не попадает под общепринятый шаблон (а, да, кстати, мы не практикуем ТДД — почему, можно отдельный пост написать) — то это означает, что где-то что-то неверно. Давайте же «мыслить ширше» ©. Не все укладывается в шаблоны и фреймворки.
Можно, дальше читать не буду ;) Следите, пожалуйста, за тем, что пишете.