技術基盤チームとして働いてみて - dunno logs
この記事は Sansan Advent Calendar 2016 - Qiita の代理記事です。年は明けてしまっていますが、残った枠が出ていたので埋めておこうかなと。 ここで話すこと 私が所属する部門で初めて技術基盤チームを置いたことの背景や、活動について 技術基盤チームを置いたことで、初めてチームが分割された時に起こったこと 弊社には運営するサービス + αの開発部門が存在するため、あくまでそのうちの一つの部門の話になります。 どういう部門の技術基盤チームか 所属する開発部門はエンジニアが入れ替わりはあれど 10 名程度所属しています。（インフラエンジニアさんは別に 2 名所属しています） 運営するサービスは足掛けでいうとおそらく運営開始からは 3 から 4 年経っていると思います。 私自身はその開発部門には 3 年程前から部署異動で参加しており、サービスの運営開始から半年から 1
自走するチームづくりをサポートするときのパターンぽいもの - Mitsuyuki.Shiiba
プロジェクトデザインパターンを読んだ。内容は企画に携わる人向けなんだけど、ちょっと言葉を変えると、エンジニアとしても「わかる！」って感じで読んでてワクワクした。良かった。 ということで「そういえば、チームづくりのサポートをするときに、ある程度パターン化してるものが僕の中にもあるなー」と思ったので、それっぽく書いてみる。 立ち止まる時間 やることが多すぎてチームが疲れている。 その状況において 少しでもタスクを早く終わらせてチームに余裕を作りたい！と、手が空いたメンバーに対して五月雨式にタスクをアサインしていると、メンバーは終わりが見えなくて疲弊してしまう。そして、効率良く作業をするほうが損をしているように感じてしまう。 そこで 5または10営業日の短い期間で区切り、その期間で終わらせるタスクを前もって共有しておく。その期間の終わりにはチームで時間を取って、何を終わらせることができたかを振り
スキルミスマッチはデスマーチの火種。資質を見極めて炎上を防げ - NaeNote
こんにちは、NAEです。 過去に何度か炎上プロジェクトを経験しました。いくら仕事をこなしても終わらない、無限のように思える暗く辛い回廊。 その多くで共通していたのが、 主要メンバーのスキルミスマッチでした。 今回はそんなお話。 コンサルティングにおけるチーム編成の仕方 スキルミスマッチが起こる理由 スキルミスマッチが織りなす害悪の嵐 本人が苦しい 周囲の人も苦しむ 最悪の場合、炎上プロジェクトへ 本人は低評価を食らうかも 仕事は人のスキルで完遂される 成長余地は資質で見極める まとめ：スキルミスマッチは害悪 コンサルティングにおけるチーム編成の仕方 まず前提として、コンサルティングの仕事でどのようにチームが編成されるかを紹介します。 プロジェクトが立ち上がることになった際、いの一番に着手するのは人集めです。提案書の中にはスケジュールがあり見積もりがあり、その裏にはどのようなスキルやケイパ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
