• Генерируем красивую Google-таблицу из своей программы (используя Google Sheets API v4)
• Начинаем работать с Google Sheets API v4/
• Работаем с API Google Drive с помощью Python

Эта вторая статья из серии. В ней мы разберём сохранение данных, функцию register_next_step_handler, напишем часть бота сбора обратной связи.

Эта статья направлена именно на новичков, в ней я постараюсь объяснить тему ботов на примере сбора обратной связи.

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

Эта статья направлена именно на новичков, в ней я постараюсь объяснить тему ботов на примере сбора обратной связи.

Привет! Это Оля Муттер, руководитель проектного офиса в СберМаркет Tech. Сегодня я хочу рассказать о проектном подходе в продуктовой разработке. Нужны ли проджекты, если в компании уже есть продакты? Как построить синергию между проектным офисом и продуктовой командой и какую пользу от этого могут получить все участники процесса, включая бизнес? Кто такие деливери менеджеры как они могут усилить вашу команду?

Моя статья будет полезной для всех участников продуктовой разработки: продактов, тимлидов, руководителей IT. Проджекты и деливери-менеджеры тоже могут узнать что-то новое.

Привет, Хабр!

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

Этот обзор предназначен для людей, которые ищут лучший инструмент для создания телеграм-ботов. Важно понимать, что не все библиотеки одинаково хороши, и правильный выбор может существенно повлиять на успех вашего проекта.

Этот обзор поможет вам сохранить время и ресурсы, а также создать более надежный и эффективный телеграм-бот на Python.

Сталкивались ли вы с трудностями при отладке Python-кода? Если это так — то изучение того, как наладить логирование (журналирование, logging) в Python, способно помочь вам упростить задачи, решаемые при отладке.

Если вы — новичок, то вы, наверняка, привыкли пользоваться командой print(), выводя с её помощью определённые значения в ходе работы программы, проверяя, работает ли код так, как от него ожидается. Использование print() вполне может оправдать себя при отладке маленьких Python-программ. Но, когда вы перейдёте к более крупным и сложным проектам, вам понадобится постоянный журнал, содержащий больше информации о поведении вашего кода, помогающий вам планомерно отлаживать и отслеживать ошибки.

Из этого учебного руководства вы узнаете о том, как настроить логирование в Python, используя встроенный модуль logging. Вы изучите основы логирования, особенности вывода в журналы значений переменных и исключений, разберётесь с настройкой собственных логгеров, с форматировщиками вывода и со многим другим.

Вы, кроме того, узнаете о том, как Sentry Python SDK способен помочь вам в мониторинге приложений и в упрощении рабочих процессов, связанных с отладкой кода. Платформа Sentry обладает нативной интеграцией со встроенным Python-модулем logging, и, кроме того, предоставляет подробную информацию об ошибках приложения и о проблемах с производительностью, которые в нём возникают.

Все знают, что в условиях большой компании очень сложно двигать крупные проекты к успеху. В таком проекте участвует много команд, каждая со своими интересами, приоритетами и особенностями, а общий объём работы — огромный. 

Если вам интересно довольно простое решение этой задачи, проверенное опытом нескольких лет и многими десятками проектов в Ozon, — смело читайте дальше!

Если, конечно, одна из них не на 8 месяце. Когда хочется сократить сроки, самым логичным выходом из ситуации может показаться увеличение количества людей в команде. В этой статье мы рассмотрим несколько исследований, чтобы понять, как размер команды влияет на ее продуктивность.

Оглавление:

Всем привет! Я Анастасия Жадринская, деливери-менеджер в Тинькофф. Да, эта статья опять про оценки и сроки выполнения задач. Сроки без вуду, астрологии, гаданий и привлечения экспертов. В статье рассмотрю метод Монте-Карло — элегантный и простой в применении математический подход для прогнозирования сроков завершения проектов или объема выпуска задач.

Возможно вы читали первую часть статьи про код ревью со стороны ревьювера (кстати, мы уже успели ее обсудить в последнем выпуске подкаста "Цинковый прод").

Так как статья набрала много лайков, пишу обещанное продолжение про код ревью с другой стороны — со стороны автора изменений кода

Как обычно, будем говорить MR (Merge Request) вместо CL, потому что термин CL мало кто понимает.

Оригинал инструкции для авторов MR по версии Google можно посмотреть здесь, а я дам краткую выжимку.

Итак, поехали

• Почему спортсмен сам идет к тренеру и рассказывает о том, что у него не получается, а в офисе часто наоборот?
• Как влиять на сотрудников?
• Как вести коллектив к цели за счет его собственной энергии?
В этой статье я постарался интересно и вдумчиво изложить свой опыт управления сотрудниками.

Привет! Я Юля, менеджер продукта в Тинькофф Кассе. Мы делаем интернет-эквайринг для бизнеса, и в разработке продукта участвуют 30 команд. При создании новой фичи какие-то команды могут действовать обособленно, но это редкость. В большинстве случаев командам при разработке нужна помощь друг друга. Расскажу, как у нас получилось сделать так, чтобы не было очередей из команд.

Хабр, привет! Я Саша, Product Manager в Ozon. Хочу сегодня поговорить с вами об исследовании зависимостей между подсистемами проекта, в частности, и повышении прозрачности процессов в разработке в общем.

Обычное дело: в команду приходит заказчик, приносит суперзадачу — киллер-фичу, которая по приблизительным оценкам будет приносить не меньше N денег в секунду. Очень важная и нужная штука. Потом проходит 3 месяца, а фича так и не появляется на проде. Более того, команда к ней так и не приступала. 

Почему? 

– вместо суперзадачи команда занимается какой-то ерундой — проблемы с приоритизацией;

– команда не поняла, что фича принесёт реальные деньги и насколько это важно — сложности с коммуникацией с заказчиком;

– недостаточно описаны требования, команда отфильтровала задачу как «не готовую к взятию в работу» — продакт не доработал;

– задача потерялась в недрах бэклога — продакт проглядел.

Все эти варианты говорят нам о наличии рассинхрона команд, ожиданий и реальности, рассинхрона подсистем относительно общего процесса, вследствие этого команда(ы) делает «не то» «не так» или не делает вовсе.

Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.

Хотели бы вы учиться эффективнее? Тогда открывайте эту статью, здесь я расскажу вам об основах эффективного обучения, а потом дам вам небольшую подборку полезных материалов для дальнейшего изучения.

Наливайте чай, присаживайтесь поудобнее и жмите кнопку "I want to know this!".

Привет, меня зовут Дима, я ведущий ИТ бизнес-партнёр в Петрович-Тех. Сегодня расскажу вам историю о том, как мы запускали продуктовый подход в инхаус-разработке.

В 2020 году задачи бизнеса сыпались в «общий котел», коллеги из бизнеса буквально бились за ИТ-ресурсы по принципу «чьё важнее». Команды разработки формировались по принципу «кто делал что-то похожее», оценки делались примерные, с умножением на «пи» или на «е».

Эта статья о том, как мы разбирали 1С УТ на продукты и сервисы, запускали “почти что Scrum-подход с элементами Kanban”, учились отвечать на вопросы “сколько ждать хотя бы примерно?” и “когда уже будет готово?” через метрики и перцентили – и как в конечном итоге благодаря продуктовому подходу нам удалось удвоить пропускную способность команд.