День рождения компании — праздник, который каждый HR ждёт с замиранием сердца, ведь каждый год мы удивляем, радуем и объединяем коллег. В июне Кошельку исполнилось 10 лет, и за это время было организовано много праздников. Но 10-летие должно было стать особенным, а ещё вовлечь удалёнщиков и отличаться от обычных вечеринок.
Рассказываем, как придумали гибрид хакатона и идеатона и делимся полезными советами по организации таких мероприятий!
Мой мадригал тем инструментам разработки, которые изменили мою жизнь
Программирование стало гораздо более многогранным ремеслом с тех пор, как в середине 1990-х я впервые попробовал AmigaBASIC. В те времена еще можно было купить один большой том о компьютере, на котором вы программируете – и там бы нашлось 99% всей нужной информации. Эта книга, где на множестве страниц уголки загнуты в качестве закладок, обклеенная стикерами, лежала бы у вас под рукой, пока вы вбивали бы команды в монохромный текстовый редактор.
Современная книга по клиентскому веб-фреймворку может быть толще, чем во времена программирования под C64 бывали мануалы, достаточные для создания полноценных игр. С другой стороны, сегодня информация по любым платформам, для которых требуется писать код, находится буквально в одном клике.
Сегодня никто бы больше и не подумал покупать документацию по разработке – и Microsoft, и Apple свободно выкладывают свою документацию в Интернете для всех желающих. А что говорить о проектах с открытым исходным кодом!
Во времена npm, PyPI и GitHub сложно объяснить, насколько неоднозначным решением (которое требовалось всесторонне обдумывать) раньше считалось потребовать хоть какие-нибудь возможности, которые выходили бы за рамки функционала операционной системы. Часто вместе с продуктом приходилось сдавать и все его зависимости.
Привет, Хабр! На связи Кирилл Маканков, руководитель направления мобильной разработки малого и среднего бизнеса в ПСБ. Недавно приложение нашего банка заняло сразу два топовых места в рейтингах мобильных банков. Третье в списке лучших банков для ИП без сотрудников и второе — в общем списке лучших мобильных банков на Android.
Этот пост о том, как мы с командой разработки этого добились, и о наших достижениях за последние два года удалёнки и пандемии. Разработчики найдут здесь интересный взгляд на свой труд «с высоты птичьего полёта». Руководители — образец для своих будущих ретроспектив, богатых экспертизой и пользой.
Но прежде всего хочу подсветить полезные советы и практики. Они помогли нам, а теперь, надеюсь, будут полезны всему сообществу.
Автор: Ричард Миллингтон (Richard Millington)
Еще в 2018 году я стоял на сцене на саммите CMX и спрашивал аудиторию, считают ли они важным доказать рентабельность инвестиций своего сообщества.
Примерно половина рук в комнате поднялась.
Превосходно!
Затем я спросил, сколько из них могут доказать рентабельность инвестиций своего сообщества.
Протянутые руки начали слабеть. Через несколько секунд лишь полдюжины рук остались поднятыми в воздухе среди моря угрюмых лиц.
Теперь пришло время для рывка.
Ежемесячно мы выпускаем срезы по IT-рынку: смотрим, какие компании публиковали больше всего вакансий, изучаем активность найма в разрезе специализаций и квалификаций. А ещё собираем эффективные вакансии за месяц: те, которые привлекли больше всего внимания специалистов.
Собрали рейтинг активности найма в сентябре — приглашаем смотреть на лидеров прошлого месяца под кат.
Привет, Хабр! Приятно удивлён, как тепло был встречен хорошо забытый формат «фуршет» (от фр. fourchette — пост, в котором одни пользователи в комментариях первого уровня объявляют себя специалистами в какой-либо теме, а другие пользователи задают им вопросы по этим темам), несколько человек даже написали в личку слова благодарности за тёплые ламповые воспоминания.
Поэтому давайте продолжим: фуршет октября объявляется открытым.
Людям свойственно со временем забывать откуда все пошло, поэтому нужно вспоминать. Публикация навеяна статьей "Почему Scrum не надо применять там, где не надо — ограничения и допущения фреймворка".
Конечно, это моя интерпретация, но она основана на огромном количестве времени обучения, самообучения и опыта в индустрии.
Понятно, что тут только про разработку ПО. И разработку длительную (в коротких проектах есть много возможностей где-то срезать углы).
Честный и понятный Agile-манифест:
В какой бы компании вы ни работали, в каком бы отделе ни числились, наверняка обращали внимание на то, что специалисты не только одного профиля, но и одного уровня выполняют определенный набор действий по-разному.
И системные аналитики – не исключение.
Обычно в компаниях принято делить специалистов на три уровня: Junior, Middle, Senior. Но по факту, градация достаточно условна, границы трактуются по-разному. Опыт работы не всегда является определяющим, да и профессиональные навыки и компетенции не всегда можно корректно измерить.
Я в системном анализе уже более 5 лет. За эти годы я достигла значительного роста как горизонтального, так и вертикального. Ежедневно я взаимодействую и консультируюсь со своими коллегами, обращаюсь к их техническим заданиям, разбираюсь в их методах реализации и наставляю новых сотрудников. В начале этого года я поймала себя на мысли, что невольно стала разделять своих коллег на 3 типа системных аналитиков.
Такая градация помогает мне определить подход взаимодействия со специалистом. А также позволяет спрогнозировать, каких результатов от этого сотрудника можно ожидать.
Привет, Коннор!
Несколько дней назад человек по имени Марис [фамилию вырезаю] нашел меня на GitHub, связался со мной и предложил роль программиста-сениора в его команде, с упором на общение с клиентами. Мне это показалось немного странным – я еще только начал учебу в колледже, и даже должность программиста-стажера мне так просто не дают. Но я принял предложение, я ведь знаю свои способности.
И вот что он, как выяснилось, делает: находит вакансии с работой по контракту, притворяется кем-нибудь из настоящих разработчиков с опытом, соответствующим требованиям в вакансии, и хочет, чтобы я проходил собеседования от лица этого разработчика. В данном случае он нашел вакансию разработчика, владеющего Laravel/React, поискал кандидатуры и решил стать тобой. Он еще и создал фальшивую почту, похожую на твою (найдешь в прикрепленном файле), для общения с клиентами.
Сомневаюсь, что такое происходит регулярно, потому что он притворяется разными разработчиками, смотря кто лучше подходит под вакансию. Но, возможно, тебе стоит ввести [вырезаю фамилию клиента] в курс дела.
Удачи,
Эндрю.
На хайпе нейронных сетей особую популярность приобрели end-to-end системы распознавания речи. И это неудивительно, ведь можно «просто» взять нейронную сеть известной архитектуры, скормить ей обучающий датасет и ждать результата. Но на практике все оказывается не так просто.
В этой статье мы попробуем рассказать, почему несмотря на эксперименты с нейронными end-to-end сетями, мы продолжаем использовать гибридную архитектуру, состоящую из акустической и лингвистической модели, работающих независимо и в чем заключаются достоинства и недостатки разных архитектур распознавания речи.
Планирование спринта является ключевым элементом работы в Scrum. Тем не менее, это все еще проблематичное и часто поверхностное событие для многих групп. Основываясь на своем опыте, я подготовил пять советов, которые помогут вам лучше спланировать свой следующий спринт.
Давно собирался написать данную статью и представить свое видение в отношении Технологии информационного моделирования (ТИМ). ТИМ имеет бесчисленное множество преимуществ при реализации, и в случае достижения результативности внедрения во все субъекты строительной отрасли можно будет наконец-то поставить жирную точку в вопросе бесконтрольности строительных процессов. Не знаю, когда удастся превратить ТИМ в привычную технологию, но …
… разве я спроста провожу параллель с Апокалипсисом?! Когда грядет тот миг воцарения цифры в стройке, тогда мир не будет прежним! Слишком фанатично. Согласен. Наяву внедрение информационных технологий происходит очень медленно, болезненно и туго, поэтому такой расклад на практике не воодушевляет и не наращивает инициатив в развитии. Но стоит представить, как эти идеи воплощаются в жизнь, сразу хочется взять и сделать чертежи в BIM (хах, нет).
Привет, Хабр.
На мой взгляд, для эффективного управления любой организацией, размера превосходящей «лоток с кебабами», важно обеспечить прозрачность и управляемость на всех уровнях.
Очень часто в различных организациях (от Банков до госорганов и ИТ-компаний) приходится решать одну и ту же проблему: как создать целостную и прозрачную картину происходящего на всех уровнях менеджмента?
Топ-менеджеры либо пребывают в состоянии ложного умиротворения по типу «В Багдаде все спокойно», либо Руководству недостаточно понятно, либо совершенно непонятно как в моменте идет достижение стратегических целей (А происходит ли?), чем заняты подчиненные и почему никто не может дать прогнозы и качественно спланировать roadmapы по ключевым проектам / продуктам. (я уже не говорю о портфелях).
Среднее звено часто изменяет стратегические цели в рамках своего их понимания и в угоду своим интересам и спускает вниз на исполнение часто в искаженном виде.
Тимлидам и командам в итоге непонятна сама стратегия, а также цели и методы ее достижения. Команды не могут взаимоувязать реализацию стратегии с целями на блоках, подразделениях, в проектах и персональными целями сотрудников.
И, конечно, ни одному из участников этой истории не нравится, когда его работу и вклад в реализацию стратегии начинают пристально рассматривать.
Казалось бы, все просто: наблюдай, управляй по исключениям и воздействуй, чтобы все пришло в требуемую норму, но нет. И причин в этом может быть масса, например, непрозрачная стратегия с целями не по SMART, отвязанная от реальной ситуации в организации...
На днях один мой знакомый получил звонок от работника ФНС с целью уточнить некоторые данные по декларации 3-НДФЛ на возврат бюджетных денег за лечение. Удивлению не было предела: мало того, что декларацию эту он не подавал (!) так и возврат уже был проверен и одобрен (!!), возврат средств предполагался на неведомый счёт в МТС-банке на его имя (!!!), нужно было лишь уточнить сущие пустяки. Небольшая, но поучительная история.
Материал заботливо подготовлен на основе перевода части книги Go With The Domain, а именно — главы 9 «Чистая архитектура» за авторством Miłosz Smółka.
В этой части говорится о том, как из wtf-кода прийти к чистой архитектуре с помощью сочетания двух идей: разделении портов и адаптеров + ограничении того, как структуры кода ссылаются друг на друга.
Российское IT-комьюнити не стесняется высказываться критически. Но что если собрать полную картину стресс-факторов, добавив злободневные проблемы и честный взгляд на разработчиков со стороны? Мы расспросили IT-специалистов различных грейдов и профилей, что их больше всего раздражает в работе.
Это глава из «Книги нормального фрилансера», в которой я делюсь опытом успешного проектировщика интерфейсов, работающего на себя.
Нужно брать с клиента столько, чтобы он не отвалился.
Где потом найдёшь другого? Лучше зря не рисковать!
Совершай скорее сделку, не продумывай деталей,
Время — деньги, пусть другие тратят время на расчёт.
Одним из самых трудных вопросов, с которыми я столкнулся на фрилансе, стал «Сколько денег взять за эту работу?» Первым клиентом волей случая оказалась компания Telphin, оператор VoIP-телефонии, довольно крупный на 2008 год. От меня требовалось спроектировать новую версию интерфейса кабинета пользователя.
Тогда в оценке я руководствовался такими понятиями, как «сколько бы мне попросить, чтобы клиент не отвалился?», «сколько вообще люди берут за подобную работу?», «за какую сумму я сам готов работать?» Тогда я назвал что-то порядка 30 000 рублей. Для студента невероятно большая сумма…
