Из плюсов ВУЗа — лекции, практика, формальное и неформальное общение с преподавателями, сокурсниками — дело обыденное, ежедневное и в какой-то мере бесплатное. Мы же не платим почасовку за то, что после лекции поговорили с преподавателем?
Искать специалиста для регулярных консультаций вне ВУЗа — это как работать с репетитором, обычно почасовая ставка. К примеру на иностранном codementor.io и аналогичных ресурсах.
Суммарно стоимость одной ежедневной часовой консультации на codementor при ставке $10/час за год будет будет составлять ~ 150 000р. Это цена равна или даже превосходит годовую стоимость обучения в ВУЗе в России. Хочу заметить, что $10/час — это очень маленькая ставка, редчайшая, её там выставляют менторы-новички для привлечения первых студентов.
Финансы — сильный останавливающий фактор. У самостоятельно обучающихся возникает недостаток общения с более опытными специалистами и передача практик.
Общение на АйТишные темы с ровесниками-единомышленниками в ВУЗе происходит так же просто как и общение на бытовые темы. Постепенно въезжают в терминологию, придумывают, экспериментируют, хвастаются, получают одобрение.
Самоучки не могут задать вопрос, который их беспокоит. Если кто-то в комментариях здесь подскажет специальный ресурс, где новичков не банят за нарушение правил дублирующихся вопросов, не троллят за низкий уровень знаний, не гнобят за банальные вопросы, за велосипедные идеи и решения — они вам спасибо скажут. Ещё ни разу не встречал преподавателя, который на вопрос про сортировку пузырьком ответит «Баааа. Гугли, ламер». Нет — они берут лист бумаги, ручку и рисуют эту схему в 1000ый раз. На популярных ресурсах вопрос-ответ за повторяющийся вопрос можно получить бан. Но они просто не умеют искать :(
Самоучки большую часть времени проводят в изоляции от единомышленников. Кто подскажет ресурс где можно найти союзника в изобретении колеса? Колесо уже изобретено. Но они начинают с колёс и велосипедов. Каждый из тысяч самоучек изобретает одинаковое колесо и стесняется признаться в том, что у него это не получается. На некоторых онлайн-курсах собирают группы студентов, но они обычно сконцентрированы на решении учебной задачи, а общение вне рамок этого задания как-то затухает. «Не интересно. Занят. Извини.»
Самоучки работают как удалённые программисты, но навыков удалённой работы не хватает. Например, они обмениваются фотографиями программного кода с экрана компьютера через WhatsUp, не знают про Skype c расшаренным экраном, не имеют гарнитуры для голосового общения, не знают про Teamviewer, не знают про расшаривание и комментирование кода через collabedit, не знают про системы контроля версий и что с автором кода можно связаться, не умеют спланировать удалённый митинг с консультантом или другими студентами из другого города и часового пояса. Они могут неделю с надеждой ждать ответ на случайно найденном заброшенном форуме 2000 года.
Тут целую статью можно писать — как самоучкам тяжело прорываться через дебри в одиночку. Если мне говорят — «я самоучка», а я вижу качественный результат — снимаю шпяпу. Мне было намного проще изучить то же самое, чем им, но у них получилось.
— Сейчас в индустрии понятие «архитектор» означает некоего человека с огромной головой, который всё всегда знает наперёд, естественно, давно отошедшего от дел и уже не марающего руки кодом. Его задача — раздавать указания тем, кто ещё не дорос до архитектора, максимум — рисовать квадратики, соединять их стрелочками. Как строительный архитектор, который рисует, но ничего сам не делает.
Мне запомнились слова тур гида на острове Крит:
Все считают архитекторов белыми воротничками в глянцевом офисе. На нашем острове пыльный архитектор в грязных сапогах носится по стройке, проверяет состав глины, качество блоков, контролирует всё. Потому что если дом по его проекту разрушится от землетрясения (землетрясения там часто бывают), когда соседские всё ещё останутся стоять — он больше заказов не получит. Карьере конец.
Замечу, что это не первая статья про «переработки — зло», в которой рассматривается перерабатывающий как лицо наёмное. Стоит только ему встать в роль нанимателя или предпринимателя, он сам же начинает рассматривать ситуацию строго наоборот. Работает больше 8 часов в день, 40 часов в неделю. Потому что интерес и страсть. Потому что ответственность. Потому что им самим же установленные сроки или договорённости.
Я не знаю, как обстоят дела у идеальных боссов, у идеальных предпринимателей, у идеальных нанимателей — мне кажется, что спокойных, размеренных, невозмутимых Мастеров Йод среди них немного.
В нашей команде Icons8 принят 100% неотклоняемый железный факт, что переработки не оплачиваются. Есть гибкий график, позволяющий перераспределить часы с одной недели на другую. Но нет оплаты за лишние часы. Если хочешь, можешь распечатать их в виде купонов по 5 минут и сделать гирлянду. Но обычно гирлянду печатать не из чего. Всё что нужно, делается в рабочее время. Всё что не нужно — не делается. Если приспичит сделать срочное внеплановое, значит задерживается плановое. Команда сама принимает решение, что важнее — плановое или внеплановое. Иногда более ценным является прикрыть глаза на срочное, иногда — потерпеть с переносом задач.
Часть обратила внимание на потраченные 100% при невыполненной работе, типа вот ведь разгильдяи, вруны, распильщики, некомпетентность на всех уровнях. Даже смертную казнь упомянули и кровавые расправы.
Часть обратила внимание что через год обнаружилась фатальная несовместимость решения.
Неправдоподобно. Там с первых строк прям ультра-косяк продакт-менеджера — тянул до последнего. Даже при ватерфлоу так запускать не получалось никогда, а уже при agile и не получится.
Я во второй половине. Обдумывая вопрос я никак не мог принять первый кейс, потому что он не укладывается в моё мировозрение. Я сосредоточился не на финансах (как заметил Calc — это не дело тим лида — и я поддерживаю, тем более что в то время я вообще с финансами компании ни разу не работал, знал только в общих чертах).
Предполагал первопричину промахов в неудачной организации работы команды, спрашивал про методику работы, про предварительную приёмку.
Ещё раз хотел бы отметить, что это вопрос с собеседования, то есть ситуация вымышленная. Задача, проверяющая ход мыслей и наличие определённого набора soft-skills. На тот момент у меня не было некоторых из них. Например, тогда я ещё не общался с заказчиками напрямую. Сейчас я просил бы моего оппонента на собеседовании принять роль заказчика в этой игровой ситуации, чтобы выяснить его мнение как заказчика. Как он отреагировал бы на правду про 20%, что он вообще думает про откладывание частей работы «на потом», готов ли он запустить частично работающий проект. Заказчик в данном случае тоже часть команды и с ним тоже надо общаться.
Дополнительно ко всему, сейчас я бы ещё на стадии собеседования принял факт, что это УЖЕ МОЙ ПРОЕКТ. Так сказать, проникся к нему душой, мысленно прожил бы его целый год. И рассматривал его как кейс, на котором надо научиться и который нужно предотвратить в будущем. И как сказал fastwit — задокументировал его для себя, для каждого в команде и даже для заказчика :)
На ум приходит история
Один маклер продул на бирже миллион баксов. Пришёл с повинной головой, рассказал боссу как всё было, в чём именно он ошибся. Предложил уволить его. Обещал вернуть частями.
Босс сказал: «Вы только что получили образование за счёт компании. Ваша учёба стоила нам 1 000 000 долларов. Идите, работайте, применяйте полученные знания на практике.»
1. Большая система чего-либо, где 20% — это искусственный интеллект. Его писали писали и ничего не получилось. Но разработчики показывали идеальную модель, отлично работающую на тестовых данных. В итоге вся система не работает.
2. Система, подразумевающая интеграцию. Но 20% этой системы находится не под контролем команды и они не готовы, хотя они отписывались об итогах и тесты проходят. В итоге вся система не работает.
3. Игра, в которой нужно определённое железо, но это за пределами программного кода проекта. Ну типа нестабильность игровой приставки. Разработчики игровой приставки обещали за год выпустить SDK с исправлениями и заменить чипы в новых версиях железа, но выпуск отложен. Вся игра работает только на пропатченных консолях у разработчиков, но они не могут патчить консоли конечных пользователей. Вся система не работает.
4. Система, в которой функционирование реализуется только путём участия третьих лиц, и привлечение этих лиц взял на себя кто-то другой, но так никого и не привели. Незнакомая ситуация? Ну представьте, что на Booking.com так и не пришли владельцы отелей. Посетители есть, отелей нет. Вся система не работает.
Хм. Ситуация понятная. В подобном довелось участвовать только со стороны разработчика, но описано очень жизненно, как при этом ПМ юлил и выёживался у заказчика. Ну и как мы относимся к коду :)
Если бы я знал что через год 20% не могут быть сделаны, я ещё до встречи с заказчиком все детали у команды выяснил. И пути решений составили бы. В целом конечно это означает «спросил у команды», но не так явно, чтобы не работать прослойкой между командой и заказчиком.
Только в моей истории я бы не дошёл до «20% не могут быть сделаны, ой» через год. Потому есть техники, которые позволяют выявить проблемы до финальной стадии сдачи. Промежуточные релизы, тестирование на контрольной группе, альфа-версии, бета-версии.
Потому что есть понятие MVP, согласно которому система реализуется частями, при котором за каждый контрольный срок реализации система дописывается сразу по всем аспектам, а не вылизывается один единственный аспект.
Пример оценки очередного цикла MVP — делать за одну итерацию срез по нескольким аспектам удовлетворённости, а не отдельный аспект.
Как пишут, первый iPhone показывали не 100% работающим :)
> «как выйти из ситуации с наименьшими потерями»
Первые три вариант финала — да, поиск такого варианта.
Такое со мной случилось бы только в случае, если мне уже сунули в руки дохнущий проект. Пришлось бы извиваться и запускать сырой, прикрыв дыры, чтобы не срывать сроки, искать свободные руки и финансы для завершения, а то и дописывать наравне с другими. В случае провала мне пришлось бы уйти, дабы не чинить расправы над выдохшейся командой.
В разработке ПО финал с человеческими жертвоприношениями — это если фейл обнаружится в системе управления космическим кораблём, логике самоуправляемого автомобиля, Скайнете, автоматической системе жизнеобеспечения в медицине. Причём умер бы конечный пользователь. А разработчик максимум отсидел бы срок, но всяко не смертная казнь. Скайнет не всчёт. Китай не в счёт.
В определённом смысле это всё риск. Надо быть готовым ко всему. Мы можем зафакапить презентацию, но и заказчик может разориться ещё до наступления года. Контрольные точки, спринты, ретроспективы — они для того, чтобы не получить фейл через год, а приблизить во времени цепочку обратной связи от заказчика и конечных пользователей. Получить фейл через 3 месяца, например.
Последний абзац, финал римейка:
И, скорее всего, оно уже даже эксплуатируется. Команда поддержки уже собирает отзывы, рекомендации, предложения, баг-репорты от конечных пользователей. Тестировщики тестируют. Дизайнеры и верстальщики улучшают интерфейс. Команда разработчиков уже доделывает проект.
Это и есть тот вариант, что мы уже давно его запустили, теперь собираем баги и дописываем код по ТЗ. Всё пучком.
флексить :) дурацкий термин, означающий что можно попробовать сдать в эксплуатацию путём урезания чего-нибудь, не в ущерб продукту в целом.
Сейчас я отвечу на такой вопрос только если мне дадут конкретный пример и возможность пообщаться с командой. Без этого я все свои пришедшие на ум советы помечу ярлычком «draft», рабочий вариант.
Бесплатно доделать — это вариант, озвученный в финале. Потому что у моей команды есть резерв. Но там не было бы 20% архитектурно-несовместимых решений.
Помню одного своего коллегу. Он когда говорил, обязательно при этом рисовал абстракции без подписей. Квадратики, кружочки, треугольники, стрелки. Ни одной надписи. По окончании разговора он вырывал лист из блокнота и отдавал. Но если я сам к этим абстракциям не приписывал надписи, на следующий это был просто листок с квадратиками и стрелками. Один из многих в моём столе. Один от другого не отличишь.
Искать специалиста для регулярных консультаций вне ВУЗа — это как работать с репетитором, обычно почасовая ставка. К примеру на иностранном codementor.io и аналогичных ресурсах.
Суммарно стоимость одной ежедневной часовой консультации на codementor при ставке $10/час за год будет будет составлять ~ 150 000р. Это цена равна или даже превосходит годовую стоимость обучения в ВУЗе в России. Хочу заметить, что $10/час — это очень маленькая ставка, редчайшая, её там выставляют менторы-новички для привлечения первых студентов.
Финансы — сильный останавливающий фактор. У самостоятельно обучающихся возникает недостаток общения с более опытными специалистами и передача практик.
Общение на АйТишные темы с ровесниками-единомышленниками в ВУЗе происходит так же просто как и общение на бытовые темы. Постепенно въезжают в терминологию, придумывают, экспериментируют, хвастаются, получают одобрение.
Самоучки не могут задать вопрос, который их беспокоит. Если кто-то в комментариях здесь подскажет специальный ресурс, где новичков не банят за нарушение правил дублирующихся вопросов, не троллят за низкий уровень знаний, не гнобят за банальные вопросы, за велосипедные идеи и решения — они вам спасибо скажут. Ещё ни разу не встречал преподавателя, который на вопрос про сортировку пузырьком ответит «Баааа. Гугли, ламер». Нет — они берут лист бумаги, ручку и рисуют эту схему в 1000ый раз. На популярных ресурсах вопрос-ответ за повторяющийся вопрос можно получить бан. Но они просто не умеют искать :(
Самоучки большую часть времени проводят в изоляции от единомышленников. Кто подскажет ресурс где можно найти союзника в изобретении колеса? Колесо уже изобретено. Но они начинают с колёс и велосипедов. Каждый из тысяч самоучек изобретает одинаковое колесо и стесняется признаться в том, что у него это не получается. На некоторых онлайн-курсах собирают группы студентов, но они обычно сконцентрированы на решении учебной задачи, а общение вне рамок этого задания как-то затухает. «Не интересно. Занят. Извини.»
Самоучки работают как удалённые программисты, но навыков удалённой работы не хватает. Например, они обмениваются фотографиями программного кода с экрана компьютера через WhatsUp, не знают про Skype c расшаренным экраном, не имеют гарнитуры для голосового общения, не знают про Teamviewer, не знают про расшаривание и комментирование кода через collabedit, не знают про системы контроля версий и что с автором кода можно связаться, не умеют спланировать удалённый митинг с консультантом или другими студентами из другого города и часового пояса. Они могут неделю с надеждой ждать ответ на случайно найденном заброшенном форуме 2000 года.
Тут целую статью можно писать — как самоучкам тяжело прорываться через дебри в одиночку. Если мне говорят — «я самоучка», а я вижу качественный результат — снимаю шпяпу. Мне было намного проще изучить то же самое, чем им, но у них получилось.
Мне запомнились слова тур гида на острове Крит:
Я не знаю, как обстоят дела у идеальных боссов, у идеальных предпринимателей, у идеальных нанимателей — мне кажется, что спокойных, размеренных, невозмутимых Мастеров Йод среди них немного.
Часть обратила внимание на потраченные 100% при невыполненной работе, типа вот ведь разгильдяи, вруны, распильщики, некомпетентность на всех уровнях. Даже смертную казнь упомянули и кровавые расправы.
Часть обратила внимание что через год обнаружилась фатальная несовместимость решения.
Я во второй половине. Обдумывая вопрос я никак не мог принять первый кейс, потому что он не укладывается в моё мировозрение. Я сосредоточился не на финансах (как заметил Calc — это не дело тим лида — и я поддерживаю, тем более что в то время я вообще с финансами компании ни разу не работал, знал только в общих чертах).
Предполагал первопричину промахов в неудачной организации работы команды, спрашивал про методику работы, про предварительную приёмку.
Ещё раз хотел бы отметить, что это вопрос с собеседования, то есть ситуация вымышленная. Задача, проверяющая ход мыслей и наличие определённого набора soft-skills. На тот момент у меня не было некоторых из них. Например, тогда я ещё не общался с заказчиками напрямую. Сейчас я просил бы моего оппонента на собеседовании принять роль заказчика в этой игровой ситуации, чтобы выяснить его мнение как заказчика. Как он отреагировал бы на правду про 20%, что он вообще думает про откладывание частей работы «на потом», готов ли он запустить частично работающий проект. Заказчик в данном случае тоже часть команды и с ним тоже надо общаться.
Дополнительно ко всему, сейчас я бы ещё на стадии собеседования принял факт, что это УЖЕ МОЙ ПРОЕКТ. Так сказать, проникся к нему душой, мысленно прожил бы его целый год. И рассматривал его как кейс, на котором надо научиться и который нужно предотвратить в будущем. И как сказал fastwit — задокументировал его для себя, для каждого в команде и даже для заказчика :)
На ум приходит история
Один маклер продул на бирже миллион баксов. Пришёл с повинной головой, рассказал боссу как всё было, в чём именно он ошибся. Предложил уволить его. Обещал вернуть частями.
Босс сказал: «Вы только что получили образование за счёт компании. Ваша учёба стоила нам 1 000 000 долларов. Идите, работайте, применяйте полученные знания на практике.»
Поставили на место.
1. Большая система чего-либо, где 20% — это искусственный интеллект. Его писали писали и ничего не получилось. Но разработчики показывали идеальную модель, отлично работающую на тестовых данных. В итоге вся система не работает.
2. Система, подразумевающая интеграцию. Но 20% этой системы находится не под контролем команды и они не готовы, хотя они отписывались об итогах и тесты проходят. В итоге вся система не работает.
3. Игра, в которой нужно определённое железо, но это за пределами программного кода проекта. Ну типа нестабильность игровой приставки. Разработчики игровой приставки обещали за год выпустить SDK с исправлениями и заменить чипы в новых версиях железа, но выпуск отложен. Вся игра работает только на пропатченных консолях у разработчиков, но они не могут патчить консоли конечных пользователей. Вся система не работает.
4. Система, в которой функционирование реализуется только путём участия третьих лиц, и привлечение этих лиц взял на себя кто-то другой, но так никого и не привели. Незнакомая ситуация? Ну представьте, что на Booking.com так и не пришли владельцы отелей. Посетители есть, отелей нет. Вся система не работает.
Это я так, наугад придумал.
Только в моей истории я бы не дошёл до «20% не могут быть сделаны, ой» через год. Потому есть техники, которые позволяют выявить проблемы до финальной стадии сдачи. Промежуточные релизы, тестирование на контрольной группе, альфа-версии, бета-версии.
Потому что есть понятие MVP, согласно которому система реализуется частями, при котором за каждый контрольный срок реализации система дописывается сразу по всем аспектам, а не вылизывается один единственный аспект.
Пример оценки очередного цикла MVP — делать за одну итерацию срез по нескольким аспектам удовлетворённости, а не отдельный аспект.
> «как выйти из ситуации с наименьшими потерями»
Первые три вариант финала — да, поиск такого варианта.
Такое со мной случилось бы только в случае, если мне уже сунули в руки дохнущий проект. Пришлось бы извиваться и запускать сырой, прикрыв дыры, чтобы не срывать сроки, искать свободные руки и финансы для завершения, а то и дописывать наравне с другими. В случае провала мне пришлось бы уйти, дабы не чинить расправы над выдохшейся командой.
В разработке ПО финал с человеческими жертвоприношениями — это если фейл обнаружится в системе управления космическим кораблём, логике самоуправляемого автомобиля,
Скайнете,автоматической системе жизнеобеспечения в медицине. Причём умер бы конечный пользователь. А разработчик максимум отсидел бы срок, но всяко не смертная казнь.Скайнет не всчёт.Китай не в счёт.В определённом смысле это всё риск. Надо быть готовым ко всему. Мы можем зафакапить презентацию, но и заказчик может разориться ещё до наступления года. Контрольные точки, спринты, ретроспективы — они для того, чтобы не получить фейл через год, а приблизить во времени цепочку обратной связи от заказчика и конечных пользователей. Получить фейл через 3 месяца, например.
Последний абзац, финал римейка:
Это и есть тот вариант, что мы уже давно его запустили, теперь собираем баги и дописываем код по ТЗ. Всё пучком.
Сейчас я отвечу на такой вопрос только если мне дадут конкретный пример и возможность пообщаться с командой. Без этого я все свои пришедшие на ум советы помечу ярлычком «draft», рабочий вариант.
Бесплатно доделать — это вариант, озвученный в финале. Потому что у моей команды есть резерв. Но там не было бы 20% архитектурно-несовместимых решений.
:)